Scott Raney wrote:
> > "the callStack" that returns the entire call chain that led to the
> > current handler.
>
> This is sort of already available: the executionError returns a
> traceback of all the script elements that were executing when the
> error occured. It's more than a "call stack", though, because it
> doesn't just include the function/message handler names.
We have found that... but it is not perfectly reliable and it only traces
back to the last "send" command.
> > "the variableNames(n)" that returns a list of all variable names used in
> > the handler that is <n> frames down the call chain (the default for <n>
> > is 0).
> >
> > "the variableScope(<name>,<n>)" that returns one of "parameter",
> > "local", "script", or "global" for the variable with the name <name>
> > that is <n> frames down the call chain.
> >
> > "the variableValue(<name>,<n>)" that returns the value of the variable
> > with the name <name> that is <n> frames down the call chain.
>
> These three would be very difficult to add ... unless the performance
> hit were acceptable
The information is already in the system... i can imagine that is difficult
to get to, but it is possible... at error time... without a general
performance hit. It is possible in C++, why not in xTalk?
> running a debugger
... is not solution to our problem. And the debugger has the problem,
too: You must anticipate the error. If it is difficult to reproduce,
you are lost. The debugger in HyperCard was much better, you'll have
to admit, but I'll have to admit that this is not a reason to generally
go back to HC ;-) ... there even was some XCMD debugger that could
display the variables up the call chain, but I forgot its name.
> > Even having only access to the callStack could help debugging very much.
> > Who else needs this? It does not have to slow down the engine, does it?
>
> Check out the executionError property and the scripts in the execution
> error dialog and see if it does what you need.
We do that already and it is helpful. But especially the problem that you
cant look behind the curtain of a send stops us from finding many errors.
Regards
R�diger
--------------------------------------------------------------------
GINIT - Gesellschaft fuer integrierte Informationssysteme mbH
--------------------------------------------------------------------
GINIT GmbH
Ruediger zu Dohna email: [EMAIL PROTECTED]
Technologiepark phone: +49-721-96681-63
Emmy-Noether-Str. 9 fax: +49-721-96681-11
D-76131 Karlsruhe www: http://www.ginit.de
--------------------------------------------------------------------
PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E
--------------------------------------------------------------------
