One point to keep in the back of your mind is that each call to scheduleAction() and executeAfter() use the same (limited) timer resource. If one queues too many items (more than 10) there will be trouble. And, there are some interactions between the page timer and the execute[]() functions. I have not completely worked out what this interaction is and I suspect that it could change from firmware version to version.

I am hedging my bets by defining my own executeThis() function. In my function I can use scheduleActions() or executeAfter() or a more complex queuing function. If I change my strategy, I only need to modify my function, not track down every action in the the program.

Now I can use:

executeThis( this );

to execute the action list on the current button. This is very handy when one needs to execute a few ProntoScript statements, then execute a few IR commands and jump somewhere. Sending IR commands by ProntoScript can be problematic if one changes the device model. (Actually, I'm using constructs that behave like the old Link pages)

While the whole procedure requires some discipline, is a little abstract and contorted, it is possible to code devices that use quite a lot of ProntoScript to send IR (or RS-232, at the flip of a global) commands and jump around, but can be freely copied from program to program without breaking tag references.