Handlers and Scope

[Trevor DeVore]

On Dec 7, 2005, at 6:47 AM, Adam wrote:
>
> I am then trying to call that function from the script of a button  
> on the card in the following way:
>
> on mouseUp
>   put field "fldItemsToFind" into lItemsToFind
>   put field "fldNumItemsAllowed" into lNumItemsAllowed
>   fMyFunction(lItemsToFind,lNumItemsAllowed)
> end mouseUp
>
> When put it into browse mode and click the button, I get Rev  
> telling me it can't find the handler fMyFunction.

When you call a function you have to put the result of the function  
into a variable.  There are two approaches:

get fMyFunction(lItemsToFind,lNumItemsAllowed)
or
put fMyFunction(lItemsToFind,lNumItemsAllowed) into tResult

The first is the Transcript short hand which puts the result returned  
from the function into the "it" variable.  The second version stores  
the result in tResult.  Another way to call the function is -

put fMyFunction(lItemsToFind,lNumItemsAllowed)

Which would print the result in the Revolution message box when  
working in the IDE.

> What is the scope of handlers in relation to the stack, cards in  
> the stack, and the elements of each card?

Ah the message path.  In your example above the function could reside  
in a number of places and still be called from the button script  
without using "send" or "call" -

1) The script of the button itself
2) If the button belongs to a group, the script of the group it  
belongs to.
3) The script of the card the button is on
4) The script of the stack the button is on
5) Any group scripts whose backgroundBehavior is set to true.
6) If the stack that the button is on is a substack of another stack  
then the script of the main stack (see "mainstack" in the Rev  
dictionary)
7) Any front or back scripts (see "insert script" in dictionary)
8) Any library stacks (see "start using" in dictionary).  This is my  
favorite place to put scripts that I need anywhere in an application.

I think that covers all of the possibilities.  I would definitely  
check out an article on the message path that Richard Gaskin has  
written <http://www.fourthworld.com/embassy/articles/ 
revolution_message_path.html>.  The message path is the other  
Revolution concept that took me a while to grasp when coming from  
other programming languages like PHP and Flash.  Understanding the  
message path is key to writing libraries and frameworks for use in Rev.

-- 
Trevor DeVore
Blue Mango Multimedia
trevor at mangomultimedia.com