use-revolution Digest, Vol 12, Issue 41

[Cubist at aol.com]

In a message dated 9/10/04 1:16:09 AM, 
use-revolution-request at lists.runrev.com writes:

>
>Message: 16
>Date: Thu, 9 Sep 2004 23:04:05 -0600
>From: "Arthur Urban" <aturban at qwest.net>
>Subject: RE: Inheritance in Revolution?
>To: "'How to use Revolution'" <use-revolution at lists.runrev.com>
>Message-ID: <000001c496f3$98d5e330$1501a8c0 at asuka>
>Content-Type: text/plain;  charset="US-ASCII"
>
>> > What I'm looking for is something in the Property Inspector 
>> that would
>> > allow
>> > me to specify an object as the script provider for another object.
>> > References like target and me would still operate as if the actual
>
>> > control
>> > were used, but it would be as if you had typed the same script into
>
>> > fifty
>> > buttons manually. Change the code in the master control, 
>> and all the 
>> > others
>> > immediately have access to the changes.
>> >
>> > Unless this ability already exists, in which case, carry on...
>> 
>> Select your 50 buttons (or whatever objects you want to inherit the 
>> script) and group them. Now put your script in the group's 
>> script, not 
>> in each buttons. If you click in one of the buttons, but there is no
>
>> "on mouseUp" in the button script, the message will pass to the 
>> button's container, in this case the group, and can be handled there.
>
>> If you want all the objects on your card to call the same 
>> handlers, you 
>> can put the handler in the card script.
>
>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.
   Well, you could put the handler(s) for those 50 buttons (or whatever other 
objects) into the stack script...

on mouseUp
  switch (the CustomClass of the target)
  case "boring normal button"
    # do "boring normal button" stuff here
    break
  case "elegant 3d button"
    # do "elegant 3d button" stuff here
  case "spiffy options button"
    # do "spiffy options button" stuff here
    break
  # and so on, and so forth, for all other CustomClass values
  default
    # shouldn't ever fall thru to this branch of the switch,
    # hence throw an error message onto the screen
  end switch
end mouseUp

>This is probably too cool a feature to ever actually see, but I can hope.
>What do the Rev Developers think? Wouldn't this add a tremendous level of
>code (and object) reusability, not to mention data/code encapsulation?
   Is there anything you'd want from this feature that can't be implemented 
via handlers in the stack script?