Handler Execution Order

[townsend]

HandlerOne calls HandlerTwo.

Once I'm in HandlerTwo, is there some way to get the name
of the calling Handler-- in this case HandlerOne?

OR-- should I just set and read a Global variable,
to keep track of the Handler execution order.

[bn]

Hi Paul,

look at

executionContexts

in the dictionary. It is going to tell you who called.

Kind regards

Bernd

[townsend]

Thanks for the quick reply Bernd!

None the less, I'm going to go with a Global variable anyway.
One of the lines in the Dictionary said,

Important: The value of the executionContexts may be changed in future versions of LiveCode, it is not recommended to write code that depends on its contents.

[bn]

Hi Paul,

I have seen people using the executionContexts.

However, I would also go your way except I maybe would send a parameter from the calling handler that indicates which handler called.

I try to avoid globals as much as I can since I find them a bit less obvious. And they are available to all open stacks. And if you're not careful who calls the global you have a hard time to debug. In fact I don't use them at all. Script local variables and custom properties are much easier to keep 'under control' than globals.

Kind regards

Bernd

[jacque]

Agree about globals, I try to avoid those too. I'll just also mention that the warning about executionContexts has been in the docs for years, and the IDE uses it too. There are quite a few people who rely on it, for better or worse, so I don't think it's as scary as it sounds. It's sure an easy way to get the info.

[mwieder]

The warning in the docs is a good one to keep in mind, but I absolutely rely on the executionContexts because in most cases there's no other way to get that data for a stack trace. There are things in the IDE that would have to change somewhat radically if the executionContexts broke. The format has changed once in the last ten years to accomodate behaviors (without notice, of course), and it changed in a way that didn't break anything existing. I would say you can safely ignore the warning but keep it in the back of your mind just in case.

[SparkOut]

A custom property would be my favourite in this situation if you have to have "something to interrogate" but otherwise I too would definitely choose Bernd's option of calling handler 2 with a parameter. It may even be the case that with a bit of judicious thought that you don't need to make a special parameter to identify the referer, but the context of any standard parameter that you passed might be sufficient to identify the different possible sources of the call.
I also get very bogged down when I try to work out "this went to that so... and that goes back to that so..." type of structures, so I really do my best to avoid this sort of thing where it is possible. I would probably use that sort of approach for things like card navigation setting a custom property of the destination card to identify the card to which to return for instance. Handler flow I try to keep as linear as possible.
I obviously don't know what issues you are facing, but as another thing to think about, perhaps also it might be possible in your situation to break out handler 2 with different 3rd and 4th subhandlers depending. Or rather, move handler 2 to become handler 4, and handlers 2 and 3 have some other independent context when they are called from handler 1 but can still use the same subhandler (now demoted to 4).
I hope these thoughts are helpful - obviously you have your own understanding of your requirements, but from my personal perspective it gives me a headache to try and keep track of flow in this manner, so where I can I avoid it.

[FourthWorld]

@OP: You may find my Flight Recorder tool useful. It's available in the Stacks section of RevNet: in the IDE choose Development->Plugins->GoRevNet

Flight Recorder is a form of message watcher, but with several benefits beyond the Message Watcher provided in RunRev's IDE:

- the calling chain is indented so you can more readily understand which handlers were called by what
- approximate relative timing info is provided to help identify bottlenecks
- you can set filters to omit specific messages or groups of messages from being logged
- double-clicking any entry in the list opens that script