I should have said - I'm assuming the standalone environment in all this.
Phil
Phil Davis wrote:
Someone please educate me...
My current understanding of the debugContext is this: it provides
access to any context listed in the executionContexts and to no other
contexts. To access a context other than the current one, you set the
debugContext to the number of the line in the executionContexts that
describes the context you want to access. (And to return to the
original context you set it to empty.)
If this is true, then it apparently can't be used in an 'errorDialog'
handler to get info about variables in the code where the error
occurred. That's because the executionContexts gets reset to show the
'errorDialog' handler as the only context. It seems to work this way
whether the errorDialog handler is in the offending script or in a
different one further along the message path.
So my question is:
When 'errorDialog' is executed, is its <executionError> parameter
(which contains error description info) the only data that's available
to help us get at the cause of the error? I can live with that, but I
would just like to know. Or am I missing something?
Like I said, someone please educate me!
Thanks to all.
--
Phil Davis
PDS Labs
Professional Software Development
http://pdslabs.net
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
