Recently, [EMAIL PROTECTED] wrote: >>> I have a field script with a keydown event >>> which responds to keys typed in a field and >>> which checks for pretyping using a handler. >>> >>> I also have a frontscript (XOS) with a generic >>> pretype handler of the same name. >>> >>> What is abnormal is that when the keydown event >>> calls the pretyping handler, the frontscript is >>> the one that takes priority and not the handler >>> in the same script! >>> >>> This busts completely the local overide principle >>> in scripts... And the hierarchy of events...
>> If I understand you correctly, I would think the behavior is correct. If >> a frontscript wasn't triggered first, why would you bother having >> frontscripts at all? > The question is rather how do you overide a frontscript?... > > In general and in most situations a local item overides a global > counterpart. > > If i have a card script and an equal stack (or bg) script, the card script > is the > first to run... > > Maybe I got the frontscript wrong... And that script shouldn't be there > but still im surprised of the behavior... Without knowing exactly what you're doing, I wonder if perhaps you need to look at the message hierarchy differently. Frontscripts were designed to intercept messages before they are passed to any object. I don't believe there is any way to override a frontscript, but you can remove the script from the message hierarchy which should effectively accomplish the same thing, and then re-insert the script as needed. Alternatively, you could have the bulk of your scripts stored in a backscript or library, and then have scripts in specific controls which will override the backscripts by default. This might be closer to what you describe. You might want to take a look at this diagram to better understand the message path: http://www.fourthworld.com/embassy/articles/images/mess_path2.gif Regards, Scott Rossi Creative Director Tactile Media, Development & Design ----- E: [EMAIL PROTECTED] W: http://www.tactilemedia.com _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
