Re: BUG OR FEATURE

[cjmiller--- via 4D_Tech]

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 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 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 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 check it. I need it as we
>>> are printing labels for samples and in one instance, we need this to
>>> be set to ease application of labels to sample tubes
>> 
>> **
>> 4D Internet Users Group (4D iNUG)
>> Archive:  http://lists.4d.com/archives.html
>> Options: https://lists.4d.com/mailman/options/4d_tech
>> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
>> **
> 
> 
> 
> -- 
> -
> Chuck Miller Voice: (617) 739-0306 Fax: (617) 232-1064
> Informed Solutions, Inc.
> Brookline, MA 02446 USA Registered 4D Developer
>   Providers of 4D, Sybase & SQL Server connectivity
>  http://www.informed-solutions.com
> -
> This message and any attached documents contain information which may
> be confidential, subject to privilege or exempt from disclosure under
> applicable law.  These materials are intended only for the use of the
> intended recipient. If you are not the intended recipient of this
> transmission, you are hereby notified that any distribution,
> disclosure, printing, copying, storage, modification or the taking of
> any action in reliance upon this transmission is strictly prohibited.
> Delivery of this message to any person other than the intended
> recipient shall not compromise or waive such confidentiality,
> privilege or exemption from disclosure as to this communication.
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: BUG OR FEATURE

[Charles Miller via 4D_Tech]

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 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 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 check it. I need it as we
> > are printing labels for samples and in one instance, we need this to
> > be set to ease application of labels to sample tubes
>
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **



-- 
-
 Chuck Miller Voice: (617) 739-0306 Fax: (617) 232-1064
 Informed Solutions, Inc.
 Brookline, MA 02446 USA Registered 4D Developer
   Providers of 4D, Sybase & SQL Server connectivity
  http://www.informed-solutions.com
-
This message and any attached documents contain information which may
be confidential, subject to privilege or exempt from disclosure under
applicable law.  These materials are intended only for the use of the
intended recipient. If you are not the intended recipient of this
transmission, you are hereby notified that any distribution,
disclosure, printing, copying, storage, modification or the taking of
any action in reliance upon this transmission is strictly prohibited.
Delivery of this message to any person other than the intended
recipient shall not compromise or waive such confidentiality,
privilege or exemption from disclosure as to this communication.
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: BUG OR FEATURE

[Jeffrey Kain via 4D_Tech]

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 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 check it. I need it as we
> are printing labels for samples and in one instance, we need this to
> be set to ease application of labels to sample tubes

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

BUG OR FEATURE

[Charles Miller via 4D_Tech]

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 check it. I need it as we
are printing labels for samples and in one instance, we need this to
be set to ease application of labels to sample tubes

Any ideas

Thanks and regards
Chuck

-- 
-
 Chuck Miller Voice: (617) 739-0306 Fax: (617) 232-1064
 Informed Solutions, Inc.
 Brookline, MA 02446 USA Registered 4D Developer
   Providers of 4D, Sybase & SQL Server connectivity
  http://www.informed-solutions.com
-
This message and any attached documents contain information which may
be confidential, subject to privilege or exempt from disclosure under
applicable law.  These materials are intended only for the use of the
intended recipient. If you are not the intended recipient of this
transmission, you are hereby notified that any distribution,
disclosure, printing, copying, storage, modification or the taking of
any action in reliance upon this transmission is strictly prohibited.
Delivery of this message to any person other than the intended
recipient shall not compromise or waive such confidentiality,
privilege or exemption from disclosure as to this communication.
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Bernd Fröhlich via 4D_Tech]

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 might be a memory leak somewhere.

Greetings from Germany,
Bernd Fröhlich
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Jeffrey Kain via 4D_Tech]

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
> need updates, if this is the case. Is there any  downside to specifying Is
> Object to be aware of?

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[David Adams via 4D_Tech]

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 problemthe very problem Jeff
reported. I don't want to go through or rehash the whole thread, it's there
in the archives for anyone that cares. But my current issue (16R3 macOS) is
a bit the same, and a bit different. The big difference is that *there is
nothing wrong with the JSON*. It's valid JSON. But 4D blows up on some of
it, some of the time and the *ON ERR CALL* does not check. Jeff's trick
with declaring Is object has at least stopped the blocking error. Now I'll
have to see if the system is actually working.

This has all been a bit slow for me as the error only appears in compiled
mode and only in one method (more on that in a moment.) And there are
nearly 6M records in my test file and over 8M in production. When you blow
up, the process is dead, you're compiled and you can't get anything back to
identify *which* record blew up. So I grafted in some logging code to log
activity before it happens so that I could figure out what the problem is.
I didn't ;-) But at least I can look and see the record.

Tim Penner made a solid point earlier about Booleans in JSON being all
lower-case. I'm wondering if that has something to do with it? Here's a
clause from the JSON:

{
  "name": "is Name Finalized",
  "old": "False",
  "new": "True"
}

Except here's the thing, those are formatted as quoted JSON strings, not
booleans. We don't want booleans, we want strings. These are valid strings.
If we wanted bools, it would look like this:

{
  "name": "is Name Finalized",
  "old": false,
  "new": true
}

Not what we want, but Tim's point is worth keeping in mind. I'm wondering
if without the Is object hint, 4D is getting overly-aggressive about
interpreting "True" and "False" (or "true" and "false") as Booleans? No
idea.

Regarding the "but my JSON is okay!" claim, here's how I checked. The 4D
bits are all in compiled mode:

-- My main big method with an *ON ERR CALL* that doesn't have any
callbacks, current method name, etc. It's either empty or Error:=Error.
This fails, and on the same record(s).
--> This method loads the data into a text array and the value is then
parsed from there, it is not directly parsed as a field

-- A big loop that scans over the same records but only copies the data
into a variable and parse it. *I don't get any errors from the same records*
.

-- Checking an individual record in an input and clicking a button that has
a little parser script. *I don't get any errors from the same records*.

-- Copy the JSON out and putting it into a JSON format window I've got (two
text vars, one in and one out.) The JSON stringify stuff works fine to
pretty print or flatten the JSON.

-- Copy the JSON out and into any JSON tool you like. No problem.

So, it's very weird. 4D blows up on the JSON in one case and no other.

If anyone can suggest why this might be happening, I'd love to hear about
it.

More to the point, should we explicitly set Is object pretty much
everywhere in our code. We have a ton of calls to *JSON Parse* that would
need updates, if this is the case. Is there any  downside to specifying Is
Object to be aware of?

Thanks!

P.S. If possible, please CC me directly in responses on dpad...@gmail.com
as I do not monitor this list.
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Bug or feature?

[Timothy Penner via 4D_Tech]

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:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Arnaud de Montard via 4D_Tech]

> 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 case

What happens in v16 with that case?
I mean I have something similar and when testing in v16 the expected "is array" 
turns to "is collection". 

-- 
Arnaud de Montard 




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Kirk Brooks via 4D_Tech]

 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 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)
>
> http://doc.4d.com/4Dv16R5/4D/16-R5/SET-DATABASE-PARAMETER.
> 301-3481818.en.html
>
> source code is stripped in a 4DC, so I wouldn't completely trust the line
> of code printing in the error dialog.
>
​Again, I agree and would do this is to track down an error.

But my fundamental question is how do I validate a string as something that
can be parsed before feeding it to JSON Parse where I'll get a runtime
error?​ That's really all I'm looking for. The solutions I'm finding so far
only work interpreted.


>
> how do you looks at the string to see if it begins with "{" or "[" ?
>
​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 case


Perhaps a better threshold definition would help.
The smallest valid object is, I think: {"a":1} or seven chars.
​The smallest valid array would be  [1] or three chars. So​

Case of

:(length($str)<2) ` a valid string could be 2 chars: {} or []

:($str[[1]]="{")&;(Length($str)<7)`  not possible
:($str[[1]]="{")

json parse

​:($str[[1]]="[")

json parse array...

End case



> besides, you shouldn't have to look at the string in the first place if
> you use JSON Parse with error handling.
>
​I don't understand. ​How can I not look at the strings to see if they are
valid if I'm getting an error attempting to parse them? 4D's parser is
strict - it gags on strings with an extra comma for example:

{"a":1, "b":2,}  but not​
​  {"a":1, "b":2} ​

​I don't have a problem with it being strict I'm just trying to understand
how to protect against runtime errors in this instance. Clearly it's in the
data. But without a way to log the error it's hard to know where to start
looking. Especially when it's the server that gets blocked by one. ​

​Perhaps I'm not handling this sort of problem the way most folks do. If so
it's out of ignorance and not intransigence. I'm happy to be guided
otherwise.

-- 
Kirk Brooks
San Francisco, CA
===

We go vote - they go home
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Bug or feature?

[Chip Scheide via 4D_Tech]

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 interpretedly.
I had to re-wright the method to insure I actually had a pointer to valid 
variable.

So... look at the method for pointer usage.


> 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 work.
> 
> I still have to use a different method to handle the error because I 
> get a -20002 (accessing a parameter that does not exist) error in 
> compiled mode. I think this -20002 error is related to my usage of $0 
> in the normal context of this method ($0 is not used in the error 
> handler context).  It looks like you also return a Boolean in $0 but 
> you do not mention seeing the -20002 error; weird. Have you have 
> provoked your error handler in compiled mode?
> 
> In either case, I have updated the code on the tech tip so it works 
> in compiled mode now; using a separate method for the error handler.
> 
> -Tim
> 
> 
> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

Hell is other people 
 Jean-Paul Sartre
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Bug or feature?

[Timothy Penner via 4D_Tech]

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 work.

I still have to use a different method to handle the error because I get a 
-20002 (accessing a parameter that does not exist) error in compiled mode. I 
think this -20002 error is related to my usage of $0 in the normal context of 
this method ($0 is not used in the error handler context).  It looks like you 
also return a Boolean in $0 but you do not mention seeing the -20002 error; 
weird. Have you have provoked your error handler in compiled mode?

In either case, I have updated the code on the tech tip so it works in compiled 
mode now; using a separate method for the error handler.

-Tim




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[arnaud--- via 4D_Tech]

> 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 ERR CALL(Current method name)
> Or as you wrote:ON ERR CALL($cmn_t)

Second option:

//IC_here -> bool
//true if 4D Internet Commands is available
C_BOOLEAN($0)
C_TEXT($1)

C_TEXT($nmc_t)
C_TEXT($oldErreur_t)
C_TEXT($error_t)

If (False)
C_BOOLEAN(IC_here ;$0)
C_TEXT(IC_here ;$1)
End if
//_
$nmc_t:=Current method name
Case of
: (Method called on error=$nmc_t)
error_l:=error
Else
error_l:=0
ARRAY LONGINT($num_al;0x)
ARRAY TEXT($nom_at;0x)
PLUGIN LIST($num_al;$nom_at)
If (Find in array($nom_at;"4D Internet Commands")>0)
$oldErreur_t:=Method called on error
ON ERR CALL($nmc_t)
$error_t:=IT_ErrorText (0)  //test IC command
$0:=(error_l=0)
ON ERR CALL($oldErreur_t)
End if
End case
//_

--
Arnaud de Montard 
(sorry, wrong address in previous)




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Arnaud de Montard via 4D_Tech]

> 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 
> name (neither the command nor the string value) to handle errors...

I do like Current method name… 
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. 

-- 
Arnaud de Montard 




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Bug or feature?

[Timothy Penner via 4D_Tech]

> 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 true.
$ob:=JSON Parse($text;Is object)
ON ERR CALL("")

But this tech tip doesn't work in compiled mode:
http://kb.4d.com/assetid=77555

However, it seems to be linked to this line in the utility method:
   ON ERR CALL(Current method name)

If I replace that line and have it call a different method for the error 
handler, it seems to work:
   ON ERR CALL("handler")

So it seems that the problem here is that you cannot use the current method 
name (neither the command nor the string value) to handle errors... I now 
wonder if this line of code (ON ERR CALL(Current method name)) ever worked in 
compiled mode - I thought I was being clever when I wrote it but maybe that is 
the source of this issue.

I can update the tech tip to be more clear about this as it does appear to work 
once that change is made.

-Tim



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Keisuke Miyako via 4D_Tech]

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)

http://doc.4d.com/4Dv16R5/4D/16-R5/SET-DATABASE-PARAMETER.301-3481818.en.html

source code is stripped in a 4DC, so I wouldn't completely trust the line of 
code printing in the error dialog.

how do you looks at the string to see if it begins with "{" or "[" ?

you can't look at $json[[1]] because the string could be length 0 (instant 
runtime error).

besides, you shouldn't have to look at the string in the first place if you use 
JSON Parse with error handling.

2018/02/02 1:09、Kirk Brooks via 4D_Tech 
<4d_tech@lists.4d.com> のメール：
​I got a runtime error on the server (v15.5) from a component. The source
of the error is probably attempting to call PARSE Json on a malformed
string (that's the line of code referenced in the error dialog). The method
looks at the string to see if it begins with "{" or "[" but that's all the
validating it does.



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[John DeSoi via 4D_Tech]

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 1, 2018, at 10:09 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> So in a compiled app I don't see how I get to the point of using tools like
> Ob is defined or OK because I don't get past the runtime parsing error. And
> I'm not able to readily determine where the offending string comes from
> because there's no way to log the error. (This particular method is reading
> JSON data coming from outside 4D.)
> 
> I hope I've missed something along the way because I'm not coming up with
> any good workarounds.

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Kirk Brooks via 4D_Tech]

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 to be aware that OK isn't updated,
> you can consult "OB Is defined" instead.
>

Let me take a step back.

​I got a runtime error on the server (v15.5) from a component. The source
of the error is probably attempting to call PARSE Json on a malformed
string (that's the line of code referenced in the error dialog). The method
looks at the string to see if it begins with "{" or "[" but that's all the
validating it does. And there is an error handler installed to catch and
ignore errors so the server doesn't get blocked.

The docs suggest using JSON Parse in just such a way to validate JSON
strings but don't mention it won't work compiled.

So in a compiled app I don't see how I get to the point of using tools like
Ob is defined or OK because I don't get past the runtime parsing error. And
I'm not able to readily determine where the offending string comes from
because there's no way to log the error. (This particular method is reading
JSON data coming from outside 4D.)

I hope I've missed something along the way because I'm not coming up with
any good workarounds.

-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Keisuke Miyako via 4D_Tech]

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 4D_Tech <4d_tech@lists.4d.com> のメール：
>
>  in the absence of a workable
> way to test the validity of a JSON string in compiled mode




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Kirk Brooks via 4D_Tech]

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 something in the JSON
Parse methods that throw that error as something that can be trapped. Not
to re hash this discussion but it sure seems like a real problem.

Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*


On Wed, Jan 31, 2018 at 4:09 PM, Timothy Penner via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> 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 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
>
> -Tim
>
>
>
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
>
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Bug or feature?

[Timothy Penner via 4D_Tech]

> 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 iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Arnaud de Montard via 4D_Tech]

> 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 why?

-- 
Arnaud 




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Bug or feature?

[Timothy Penner via 4D_Tech]

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 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

-Tim



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Kirk Brooks via 4D_Tech]

Has anything moved on this issue?

Just today I was getting runtime errors on the server. You know, the open
dialog, processes hung up. Sigh. It was in a component so i dug into to see
why the error was propagating to the level of stopping things and found
exactly this situation.

Even more, in the midst of looking at things I noticed this quote on the JSON
Parse <http://doc.4d.com/4Dv15/4D/15.5/JSON-Parse.301-3577097.en.html>
docs:

"This string must be formatted correctly, otherwise a parsing error is
generated. JSON Parse can therefore be used to validate JSON strings."

​And thought: uh - cool. I'll just make a method to test strings more
completely. And ran right into this issue when it's compiled. ​


I hate this sort of stuff.

Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*


On Fri, Mar 3, 2017 at 7:06 AM, Jeffrey Kain via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> The following behaves differently in interpreted vs. compiled:
>
>   C_OBJECT($oResponse)
>   C_TEXT($tResponse)
>
>   ON ERR CALL("ErrHandler")
>   $tResponse:="False"
>   $oResponse:=JSON Parse($tResponse)
>   ON ERR CALL("")
>
> In interpreted mode, the error handler catches an Error value of 54, and
> $oResponse is undefined.
>
> In compiled mode, the error handler catches an Error value of -1, and then
> 4D throws a runtime error dialog on the screen for JSON Parse ("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
> error of -1 in the error handler and no runtime error is generated.
>
> Feature or bug?
>
> --
> Jeffrey Kain
> jeffrey.k...@gmail.com
>
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Bug or feature?

[Epperlein, Lutz (agendo) via 4D_Tech]

> 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 this short 
article about Java's RunTimeException (a more or less official statement in the 
docs of Java):


I quote from there:
> Here's the bottom line guideline: If a client can reasonably be expected to 
> recover 
> from an exception, make it a checked exception. If a client cannot do 
> anything to 
> recover from the exception, make it an unchecked exception.

Regards
Lutz

--  
Lutz Epperlein  
--
Agendo Gesellschaft für politische Planung mbH
Köpenicker Str. 9
10997 Berlin
http://www.agendo.de/
--


**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[David Adams via 4D_Tech]

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
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[David Adams via 4D_Tech]

> 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 Component log)
> to the developer", etc.

Well, this doesn't happen every day...I read an email post on the list and
change my mind. You're right, I've been looking at the error call mechanism
in the wrong way forever. Yes, there are two kinds of errors:

Open file
It's locked!
Get array element 5
There are only 4 elements!
The first error is manageable, the second...not so much. The second sort of
error does put the program in an uncertain and unpredictable state and the
error must not be ignored. I've quoted you and added a bit of commentary to
this recent feature request thread:

ON ERR CALL method: Intercept all types of errors
http://forums.4d.fr/Post/EN/17994245/1/17994246
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[John DeSoi via 4D_Tech]

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 while 
the process on the other side of the connection waits forever is not a good 
solution. 

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.

John DeSoi, Ph.D.


> On Mar 3, 2017, at 6:00 PM, Keisuke Miyako via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> I wrote this almost ironically but maybe there is something to it.
> 
> 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 Component log) 
> to the developer", etc.

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Kirk Brooks via 4D_Tech]

Jeff,
I vote for bug. Though it could be it's 2 different errors as far as 4D is
concerned with a compiler error tripping first which doesn't show up
interpreted.

I've noticed -1 being returned as an error code for a really wide range of
errors. Or, it's a case like this where the compiler trips before the
actual coding error does. It makes it harder to figure out nonetheless.

On Fri, Mar 3, 2017 at 7:06 AM, Jeffrey Kain via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> The following behaves differently in interpreted vs. compiled:
>
>   C_OBJECT($oResponse)
>   C_TEXT($tResponse)
>
>   ON ERR CALL("ErrHandler")
>   $tResponse:="False"
>   $oResponse:=JSON Parse($tResponse)
>   ON ERR CALL("")
>
> In interpreted mode, the error handler catches an Error value of 54, and
> $oResponse is undefined.
>
> In compiled mode, the error handler catches an Error value of -1, and then
> 4D throws a runtime error dialog on the screen for JSON Parse ("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
> error of -1 in the error handler and no runtime error is generated.
>
> Feature or bug?
>
> --
> Jeffrey Kain
> jeffrey.k...@gmail.com
>
>
>
>
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **




-- 
Kirk Brooks
San Francisco, CA
===
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[John DeSoi via 4D_Tech]

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 DeSoi, Ph.D.


> On Mar 3, 2017, at 9:06 AM, Jeffrey Kain via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> In compiled mode, the error handler catches an Error value of -1, and then 4D 
> throws a runtime error dialog on the screen for JSON Parse ("Attempting to 
> retype by using a pointer.") even though an ON ERR CALL is still in effect.

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Bug or feature?

[Chip Scheide via 4D_Tech]

came across this minutes before your post...
not related  but I could not help myself  :)
https://i.redd.it/njhwg6drc2jy.jpg

On Fri, 3 Mar 2017 10:06:18 -0500, Jeffrey Kain via 4D_Tech wrote:
> The following behaves differently in interpreted vs. compiled:
> 
>   C_OBJECT($oResponse)
>   C_TEXT($tResponse)
> 
>   ON ERR CALL("ErrHandler")
>   $tResponse:="False"
>   $oResponse:=JSON Parse($tResponse)
>   ON ERR CALL("")
> 
> In interpreted mode, the error handler catches an Error value of 54, 
> and $oResponse is undefined.
> 
> In compiled mode, the error handler catches an Error value of -1, and 
> then 4D throws a runtime error dialog on the screen for JSON Parse 
> ("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 error of -1 in the error handler and no runtime error is generated.
> 
> Feature or bug?
> 
> --
> Jeffrey Kain
> jeffrey.k...@gmail.com
> 
> 
> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Bug or feature?

[Jeffrey Kain via 4D_Tech]

The following behaves differently in interpreted vs. compiled:

  C_OBJECT($oResponse)
  C_TEXT($tResponse)

  ON ERR CALL("ErrHandler")
  $tResponse:="False"
  $oResponse:=JSON Parse($tResponse)
  ON ERR CALL("")

In interpreted mode, the error handler catches an Error value of 54, and 
$oResponse is undefined.

In compiled mode, the error handler catches an Error value of -1, and then 4D 
throws a runtime error dialog on the screen for JSON Parse ("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 error 
of -1 in the error handler and no runtime error is generated.

Feature or bug?

--
Jeffrey Kain
jeffrey.k...@gmail.com




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**