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 di
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 b
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 dev
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
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 mig
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
> n
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.
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/faqnu
> 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 c
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 cod
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 interpreted
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
> 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
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)
-Tim
**
> 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
> na
> 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
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
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
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 t
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_T
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
> 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 i
> 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
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
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
> 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 t
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
***
> 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 Componen
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 whil
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 i
from what you describe,
- the Compiler
- ON ERROR CALL
- JSON Parse
all seem to be working as expected.
if there is a bug,
I would argue that it is in the documentation,
for furnishing the wrong kind of expectations in these features.
---
the alternative, to "correct" any of the aforementioned
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 b
Agreed. I think it's also a bug that we have a significant difference of
behavior interpreted vs. compiled.
> On Mar 3, 2017, at 10:59 AM, John DeSoi via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> Bug in my opinion that 4D shows any error dialog while the error handler is
> active. This is a
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
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($t
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
36 matches
Mail list logo