Inheritance in Revolution?

[Richard Gaskin]

Arthur Urban wrote:
> 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