Getting the messages/handlers available for a button

[Len Morgan]

On 3/28/2010 2:19 PM, J. Landman Gay wrote:
> Len Morgan wrote:
>> This should be so simple but I can't get the instructions in the 
>> documentation to work:
>>
>> What I'd like to know is what handlers are available to a button.  
>> This would include not only scripts I've written for the button but 
>> also the ones that Rev has builtin (like mouseUp). 
>
> Open the dictionary, and in the panel at the left under the Objects 
> category, click "Button". That lists all relevant button info.
>
I wish this were so but while there are some messages there, many are 
missing.  For example, I'm not sure why "socketClosed" is listed under 
Object->Button but "mouseUp" is not.  The "messages" entry does have 
mouseUp but doesn't tell me it's sent to buttons.  What I guess I need 
is all of the entries from the messages category that apply to buttons 
(for example).  Is there a way to get this?
>> It would be really cool if I could get any handlers along the way 
>> like in groups, cards, stacks that this button (or whatever control 
>> for that matter) is contained in/on.
>
> The message hierarchy only works in one direction, starting from the 
> object that first receives the message and moving on toward the 
> engine. That means that you can't easily retrieve messages sent to an 
> object farther along the hierarchy unless you specifically use a 
> "send" command to re-route it, or insert a frontscript to catch it 
> before anything else does. Behaviors are the single, limited 
> exception; they push a message "backward" to a subscribing object, but 
> after that the message goes through the hierarchy normally.
>
I think you might have misunderstood what I was asking for here.  What I 
was suggesting was a way to map a message from, for example, a button to 
a group to a card to a stack to a library to the engine (with maybe a 
front and back script if appropriate).  I guess it wouldn't be too hard 
to cobble something together that worked like traceroute does (tracert 
for Windows users), and get the long ID of a control, get a list of the 
messages in it's script, then for each message, send the message to the 
next object in the long ID (group, card, etc) and see if I get an 
error.  The only problem would be the unintended consequences of firing 
a message that might do some damage (like a "Delete Everything in Sight" 
button.  :-)

len morgan