Re: BUG OR FEATURE

You got it. 64 bit works. I think documentation should be updated Sent from my iPhone > On Feb 4, 2019, at 2:36 PM, Charles Miller via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > It might be I will check when I next am at that client.n If that is > the case then documentation should show the

Re: BUG OR FEATURE

It might be I will check when I next am at that client.n If that is the case then documentation should show the differences. Thanks for giving me a place to look. Regards Chuck On Mon, Feb 4, 2019 at 2:23 PM Jeffrey Kain via 4D_Tech <4d_tech@lists.4d.com> wrote: > > Could it be the difference

Re: BUG OR FEATURE

Could it be the difference between a 32-bit client and a 64-bit client? 64-bit clients on Mac get access to more printer driver features than the 32-bit client. > On Feb 4, 2019, at 2:17 PM, Charles Miller via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > When I am connected to an uncompiled

BUG OR FEATURE

Hi all, Version 16.4 Mac OSX 10.13 clients. When I am connected to an uncompiled development server and I bring up print settings, I can see a check box Reverse Page orientation and can change it. When I connect to a merged server, with a built client, this check box is not visible and I can not

Re: Bug or feature?

David Adams: > If anyone can suggest why this might be happening, I'd love to hear about it. If I understood your description correctly, then the code only blows up if you process lots of data and not if you test every piece of data individually. If that is the case then I would guess there

Re: Bug or feature?

This is what we do everywhere now. In our case, we're never gonna JSON Parse a longint, so we just wrapped it. -- Jeffrey Kain jeffrey.k...@gmail.com > On Apr 5, 2018, at 7:39 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > We have a ton of calls to *JSON Parse* that would >

Re: Bug or feature?

Hey, long thread - I was even part of it at some point. I just wanted to send out a big *thank you* to Jeff Kain for starting it. (And to Chip for the awesome feature bug picture.) I'm writing now because I've been banging my head against the desk for a couple of days trying to get past a problem

RE: Bug or feature?

Hi Kirk, Please try the updated code available here: http://kb.4d.com/assetid=77555 I updated the tech tip yesterday and it works in compiled mode now. -Tim ** 4D Internet Users Group (4D iNUG) FAQ:

Re: Bug or feature?

> Le 2 févr. 2018 à 03:15, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > ​I use a case statement like: > > Case of > > :(length($str)<2) ` a valid string could be 2 chars: {} or [] > > :($str[[1]]="{") > > json parse > > ​:($str[[1]]="[") > > json parse array... > > End

Re: Bug or feature?

Miyako, On Thu, Feb 1, 2018 at 12:33 PM, Keisuke Miyako via 4D_Tech <4d _t...@lists.4d.com> wrote: > I don't think that actually proves that JSON Parse is throwing the > runtime error. > ​Agreed. But that is where it shows up so it's the place to start.​ rather than looking at the "line of

RE: Bug or feature?

I just today got the -20002 error in a compiled database. The issue is/was pointers. I was doing something "fancy", basically the pointer was not pointing to what I thought it was, it was actually pointing to a nonexistent variable - via Get Pointer. All of this code worked perfectly

RE: Bug or feature?

Arnaud, Thank you, this led me to reinspect my code and I found a couple issues with the original code. The issue I was seeing was actually multiple issues compounded together that led me to think it didn’t work. You are correct, using the current Method Name for an error handler does seem to

Re: Bug or feature?

> Le 2 févr. 2018 à 00:30, Timothy Penner a écrit : > > Arnaud, > >> Most of the time I do this at beginning: >> $cmn_t:=Current method name >> then I use $cmn_t. >> I don't remember of problems in compiled. > > But do you use the current method to handle errors? > Either: ON

Re: Bug or feature?

> Le 1 févr. 2018 à 22:14, Timothy Penner via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > >> besides, you shouldn't have to look at the string in the first place if you >> use JSON Parse with error handling. > > So it seems that the problem here is that you cannot use the current method >

RE: Bug or feature?

> besides, you shouldn't have to look at the string in the first place if you > use JSON Parse with error handling. Hmmm, this does seem to work in compiled mode: C_OBJECT($ob) C_TEXT($text) ON ERR CALL("handler") $text:="{\"OK\": True}" // The JSON is invalid because True should be written as

Re: Bug or feature?

I don't think that actually proves that JSON Parse is throwing the runtime error. rather than looking at the "line of code referenced in the error dialog" perhaps you could activate debug log recording in verbose mode (2) at the start of the offending method (and disable it a the end)

Re: Bug or feature?

There are no work-arounds for runtime errors. 4D throws up an error dialog and allows the end user to decide what to do, even if executing on 4D Server or in a web process. See feature request and discussion here: http://forums.4d.com/Post/EN/17994245/1/19128922 John DeSoi, Ph.D. > On Feb

Re: Bug or feature?

Hi Miyako, On Wed, Jan 31, 2018 at 9:55 PM, Keisuke Miyako via 4D_Tech < 4d_tech@lists.4d.com> wrote: > JSON Parse error can be handled with ON ERR CALL, because it is not a > runtime error. > > "Current method name" requires range checking (see docs), but that is > unrelated. > > you just have

Re: Bug or feature?

JSON Parse error can be handled with ON ERR CALL, because it is not a runtime error. "Current method name" requires range checking (see docs), but that is unrelated. you just have to be aware that OK isn't updated, you can consult "OB Is defined" instead. > 2018/02/01 14:20、Kirk Brooks via

Re: Bug or feature?

Hey Tim, Thank you for the references. You are always so prompt with spot on links like that. I get the thinking about runtime errors - but in the absence of a workable way to test the validity of a JSON string in compiled mode it seems a good place for an actual method to do this. Or writing in

RE: Bug or feature?

> I don't see why? Because runtime errors are not caught in compiled mode: { Tech Tip: Range checking errors are not caught by ON ERR CALL in compiled mode http://kb.4d.com/assetid=77848 } -Tim ** 4D Internet Users Group (4D

Re: Bug or feature?

> Le 1 févr. 2018 à 01:09, Timothy Penner via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Hi Kirk, > > [...] > > We also have this tech tip - but I suppose it doesn't work in compiled mode... > Tech Tip: How to check if TEXT is an OBJECT / JSON > http://kb.4d.com/assetid=77555 I don't see

RE: Bug or feature?

Hi Kirk, Have you seen these tech tips? Tech Tip: Range checking errors are not caught ON ERR CALL in compiled mode http://kb.4d.com/assetid=77848 Tech Tip: Consider disabling "Interact with the desktop" when running 4D Server as a Service http://kb.4d.com/assetid=77847 We also have this tech

Re: Bug or feature?

se ("Attempting > to retype by using a pointer.") even though an ON ERR CALL is still in > effect. > > If I change the JSON Parse line to: > > $oResponse:=JSON Parse($tResponse;Is object) > > ... then 4D behaves the same in interpreted and compiled. Both catch an >

RE: Bug or feature?

> Most programming environments have a way to deal with runtime errors. Many > good ones have constructs like try/catch/throw. 4D really needs something > like this. I second this too, it would be much better than the present state. But regarding the discussion about runtime errors, pl4ease read

Re: Bug or feature?

On Sat, Mar 4, 2017 at 11:41 AM, John DeSoi via 4D_Tech < 4d_tech@lists.4d.com> wrote: > > Most programming environments have a way to deal with runtime errors. Many > good ones have constructs like try/catch/throw. 4D really needs something > like this. > +100

Re: Bug or feature?

> I still hold the view that ON ERROR CALL should not apply to runtime errors, > as there are no logical ways to recover from them, but would a "feature" that > allows the customisation of the runtime error dialog make sense? one that > includes such options as "send information (e.g. Info

Re: Bug or feature?

There is no way to recover, but the 4D dialog can capture the exact error and line number and give the user two options, Abort and Continue? I would be fine with 4D aborting the process and writing the error information to the event log. Showing the dialog on the on the server or web server

Re: Bug or feature?

; $oResponse:=JSON Parse($tResponse;Is object) > > ... then 4D behaves the same in interpreted and compiled. Both catch an > error of -1 in the error handler and no runtime error is generated. > > Feature or bug? > > -- > Jeffrey Kain > jeffrey.k...@gmail.com > >

Re: Bug or feature?

Bug in my opinion that 4D shows any error dialog while the error handler is active. This is a huge problem for execution on 4D Server or a web server. And if it happens in front of a user they can just hit abort and you have no way to know about the problem unless they complain about it. John

Re: Bug or feature?

JSON Parse line to: > > $oResponse:=JSON Parse($tResponse;Is object) > > ... then 4D behaves the same in interpreted and compiled. Both catch > an error of -1 in the error handler and no runtime error is generated. > > Feature or bug? > > -- > Jeffrey Kain > jeffrey

Bug or feature?

ge the JSON Parse line to: $oResponse:=JSON Parse($tResponse;Is object) ... then 4D behaves the same in interpreted and compiled. Both catch an error of -1 in the error handler and no runtime error is generated. Feature or bug?