I have several event handlers for common events such as mouseUp,
openCard, menuPick, closeField which are installed as front scripts.
The reason for this is to grab these events as soon as possible in
order to handle any updating of the SQLite database I use to store the
data for my app. The handlers do various checks to make sure they
need to handle the message, take action if necessary, and pass the
message on so the handlers for these events in the controls themselves
can take any further action needed.
This all works quite nicely although I've experienced some grief and
hard freezes because of things like mouseUp coming from unexpected
places like the IDE stack objects or the script editing window in
debug mode. I suspect I'm taking some performance hits as well since
every single one of these events has to go through my front script
handler.
I'm wondering if it might be better to do this by having behavior
scripts for each type of control. That would eliminate the need for
checking that I'm dealing with a control I care about, the issues with
events coming from unexpected places, and any performance issues. On
the downside, I'd need to come up with a way to allow each control to
carry out any local processing it needs to take care of (dispatch?).
It would also involve a small amount of extra work to specify the
behavior every time I add a control unless I developed my own tool
palette that had the controls already set up with the correct behavior
so I could drag and drop them where I wanted them.
I'd appreciate some guidance on this, either philosophical or practical.
Thanks,
Pete Haworth
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
