I probably wasn't as clear as I could have been. These 50 buttons all live on different cards, different sub-stacks, etc. Think of this ability as one might approach a Password Field. You'd write the clever text hiding code in the field's script, and then maybe use this field in two or three different locations. When you discover that bug, you just change the master script, and no matter where the other buttons happen to be, they gain the benefit of the fix without extra copy/paste efforts.
You might find libD'oh! amusing: <http://www.fourthworld.com/rev/downloads.html>
It's a "poor man's OOPS" (pardon the Simpsons pun), illustrating a technique using a frontscript to allow different behaviors for objects differentiated by a "class" property.
For example, if you wanted a custom behavior for mouseUp for just some objects but not others, you could set a "class" property of those objects to contain a class name. In a substack somewhere you have a bunch of buttons that hold the scripts that define each class.
The frontScript traps the mouseUp message and checks the class property -- if empty it passes it as normal, but if the class is defined it sends the mouseUp message to the button that defines the behavior for the class.
Sounds complicated to set up, but once you have it it's not hard to use. I don't use it much myself because frontScripts only trap system messages and a lot of my stuff is driven by custom handlers. But it was a fun experiment, and may spark some useful solutions for you.
-- Richard Gaskin Fourth World Media Corporation __________________________________________________ Rev tools and more: http://www.fourthworld.com/rev _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
