Peter Haworth wrote:

I have a number of message handers set up as front scripts to carry out standard processes on any cards in my stack,things like closeField, selectionChanged, etc. The problem is it appears that these scripts are being executed when the events they handle come from the Rev IDE, which causes some pretty severe problems. I'm quite surprised that the IDE would pass it's events to my front scripts since they are part of my application not the IDE but be that as it may, I need to find a way around this issue.

I've made execution of my front script code dependant on the current tool being the pointer but that doesn't help when I'm in edit mode to modify cards or scripts.

I guess my question is whether there is a better place to put these scripts in the message path to avoid them being called from the IDE, or if there is some reliable way to check if the messages they receive are coming from my application stacks and not the IDE.

Forgive the seeming tautology, but put your handlers where you need 'em. ;)

FrontScript are handy, but they're available for a very specific purpose: to catch ALL messages BEFORE objects get them.

If you need both of those conditions met, frontScripts will be hard to beat. But for everything else there are many options:

- mainStack script: that way you'll only get the messages sent to your main stack or substacks

- use "if" to differentiate whether to handle message or not, looking for something like

   if the effective filename of this stack is "MyStack" then...

- behaviors: assigning a behavior script to your objects will let you handle those messages only for the objects to which the behavior is attached.

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/articles/revolution_message_path.html>

Note for Mark Wieder: Yes, I finally got around to adding mention of "dispatch" there. :)

--
 Richard Gaskin
 Fourth World
 Rev training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
 revJournal blog: http://revjournal.com/blog.irv
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to