Universal handler trap.

[dunbarx]

This was brought up a while ago, not by me.

Add a universal handler trap in the engine, way in front, that could be analyzed at will. In other words, before any frontscripts, offer a control structure like:

on preHandler theMessage,paramList, [theCallingEvent | theCallingObject]
...
end preHandler

or somesuch.

All handlers, including even those using reserved words like "set", can then be examined before they even enter the message path, regardless of where or how they originate. The "paramlist" is just a name for whatever text follows the command, function or message that triggers prehandler itself. The control structure could not be used in a script, and would likely only ever be useful if examined in the script editor.

I think it would be marvelous.

[FourthWorld]

With frontScripts you can trap any specific message before the target object.

To catch all messages without having to specify each of them there's a pair of undocumented messages called messageHandled and messageNotHandled. By default these aren't sent, to keep the message queue trimmed for efficiency. But if you need them you can set the messageMessages global property to true, and then those messages will be sent.

Personally I've never had a use for messageNotHandled, but I use messageHandled in a logging tool called FlightRecorder which has at times been a godsend for tracking down odd interactions.

The only downside with these messages is that they don't currently send params with them - there's an RQCC request for that, however:
http://quality.runrev.com/qacenter/show_bug.cgi?id=2569

[dunbarx]

Richard.

Thanks for the reply.

messageMessages, eh? What will they think of next/

Craig

[FourthWorld]

That may be why it's undocumented, until they come up with a better name.

[acidjazz]

Richard,

Could you share your flightrecorder tool? I have a stack with a card that has a mind of its own. It appears for about 4 seconds and then moves onto the card that I'd programmed it to in a "next" button, but without the next button being clicked. The card has no script, and I deleted the "next" button for that card, and yet it still occurs! I suspect that a message sent from elsewhere in the stack is causing this, and it's taking 4 seconds for the message to "arrive". Unfortunately, I can't locate any script in the entire stack that would cause this behavior. So, I need to know what message occurs immediately prior to this behavior, and hopefully, where the message is coming from. Your flight recorder would seem to be the solution.

Help!
Mark

p.s. I should mention that I don't know how to use frontscripts, and so don't know how to create my own flightrecorder. I tried using the term "messagehandled" in tRev and found that Jerry has his own flight recorder, but I don't quite understand it either. My programming self-esteem is getting lower by the minute...

p.p.s. I solved the problem! But I would still be very interested in a flight recorder.

[FourthWorld]

For working with frontscripts this article may be helpful:

Extending the Runtime Revolution Message Path:
An introduction to using Libraries, FrontScripts, BackScripts and Behaviors
in Runtime Revolution's RevTalk Programming Language
http://www.fourthworld.com/embassy/arti ... _path.html

As for Flight Recorder, I've uploaded it to RevNet - in Rev, see Development->Plugins->GoRevNet, and in RevNet see 4W_FlightRecorder in the Stacks section.

[acidjazz]

Very nice! Thanks!
Mark