Universal handler trap.

Something you want to see in a LiveCode product? Want a new forum set up for a specific topic? Talk about it here.

Moderators: Klaus, FourthWorld, heatherlaine, robinmiller, kevinmiller

Post Reply
dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6026
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Universal handler trap.

Post by dunbarx » Fri Jan 08, 2010 10:07 pm

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6673
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Universal handler trap.

Post by FourthWorld » Sat Jan 09, 2010 1:31 am

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
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6026
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Universal handler trap.

Post by dunbarx » Fri Jan 15, 2010 3:59 pm

Richard.

Thanks for the reply.

messageMessages, eh? What will they think of next/

Craig

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6673
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Universal handler trap.

Post by FourthWorld » Fri Jan 15, 2010 5:43 pm

That may be why it's undocumented, until they come up with a better name. :)
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

acidjazz
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 93
Joined: Mon Feb 16, 2009 2:37 am
Location: Tampa, FL

Re: Universal handler trap.

Post by acidjazz » Thu May 20, 2010 3:55 am

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6673
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Universal handler trap.

Post by FourthWorld » Thu May 20, 2010 3:48 pm

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.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

acidjazz
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 93
Joined: Mon Feb 16, 2009 2:37 am
Location: Tampa, FL

Re: Universal handler trap.

Post by acidjazz » Sun May 23, 2010 5:53 pm

Very nice! Thanks!
Mark

Post Reply

Return to “Feature Requests”