Mark Waddingham wrote:
> On 2016-04-13 22:46, Richard Gaskin wrote:
>> Ralph DiMola wrote:
>>
>>> It works in a library stack. In fact it also catches IDE errors.
>>
>> Thanks. I found the culprit: I hadn't yet turned off "Debug Mode"
>> (still don't know why the default is to create yet one more
>> difference between IDE and runtime, but oh well...)
>
> Perhaps because the assumption is that most people when using a dev
> tool will actually want interactive debugging by default ;)
You might think so, until the user explicitly expresses a desire to
handle the errorDialog message themselves by writing an errorDialog handler.
But that's just a design decision. What seems obvious to you or to me
or anyone else may differ from time to time. That's ok.
The weird part is how it works - or perhaps doesn't work:
I have this in a button:
on mouseUp
throw "Some random message"
end mouseUp
...and this in the stack script:
on errorDialog
put the params
end errorDialog
My stack's errorDialog message never triggers, but the one in
revbackscriptlibrary does.
That seemed weird to me, so I thought perhaps one of the debug messages
is trapping something else and explicitly sending "errorDialog", so I
added this to the errorDialog handler in revbackscriptlibrary just below
the handler declaration (which was in itself an odd exercise -
<http://quality.livecode.com/show_bug.cgi?id=17400> ):
put the executionContexts
What I get in the message box is just two lines:
- the errorDialog handler in revbackscriptlibrary
- mouseup from the button that starts the execution path.
What could cause all other scripts to be bypassed to favor one
particular backscript?
This was interesting:
> That being said, there is a bughancement (I can't quite decide
> whether it should be considered a bug or not - it is how the
> engine's debugger has always worked after all) here to have
> throwing of errors work the same way in the debugger as other
> dev tools. i.e. The debugger should break when a throw occurs,
> but then not actually interrupt normal processing when you
> continue to execute.
Doesn't sound related to what I'm seeing with the odd message path for
errorDialog - could it be?
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
