Activating a Function in a Different Stack

[Marielle Lange]

>  Is it possible to activate a function that resides in one stack,  
> and get
> the result from a different stack?

It is possible,

------------------------------------------------------------------------ 
-----------------------------------------------------------------------
A. The send equivalent for functions according to the manual:

value("the name of me", card 1)

Stack A -  one button with the following script:
---------
	on mouseup
		 answer value("doSomething(" & quote & "one" & quote & "," & quote  
& "two" & quote &")", button 1 of stack "stackA")
	end mouseup

Stack B - one button with the following script:
---------
	function doSomething p1, p2
		 return "done", p1, p2
	end  doSomething


------------------------------------------------------------------------ 
-----------------------------------------------------------------------
B. Difficulties with this solution

The problem is that you cannot refer to any object on the card as all  
references are made relative to the calling object, not the one that  
receives the call.

As the doc says: "If you specify an object, references to me in the  
expression are treated as references to the object. However, other  
object references are treated as though the handler were in the  
current object's script. For example, "button 3" refers to button 3  
on the current card, not the card where the object is located."

Illustration of the problem.

Stack A -  one button with the following script:
---------
	on mouseup
		answer value("doSomething(" & quote & "one" & quote & "," & quote &  
"two" & quote &")", button 1 of stack "stackA")
	end mouseup

Stack B - one button and a field:
---------
	function doSomething p1, p2
		put p1,p2 into field 1
		return "done"
	end  doSomething

You will get an error. field 1 cannot be found, it doesn't exist on  
stack A. To use "put p1,p2 into field 1 of this stack" will not make  
any difference. This stack is stack A in this context. In stack B,  
you have to write your object references in full:

	put p1,p2 into field 1 of card 1 of stack "stackB"

If your function on stack B calls a function or handler at card or  
stack level, the call will happen. But any reference to any object  
within that handler or function will be relative to the calling  
script (stack A), not stack B, with the same problem again.

So, to get the backgroundcolor propery of stackB you would have to write
	return the backgroundcolor of stack "stackB" -- or whatever the name  
of your stack is

------------------------------------------------------------------------ 
-----------------------------------------------------------------------
C. The Custom Properties way

Your post suggests that you are already familiar with reading and  
writing custom properties across objects. You can use custom  
properties to read data the same way you can use them to send data.

Because of the nightmare of passing parameters with the value  
construct (you can easily end up spending 30 min. on this to get the  
quoting correct) as well as the problem that references are relative  
to the calling object, rather than the receiving one, I tend to  
prefer to use custom properties.

Stack A
---------
	on mouseup
		send doSomething to stack "stackB"
		wait 1 tick (in case of, I believe that's not needed but I tend to  
add it)
		put the handlername_result of stack "stackB"  into tResult.   <---   
reading the custom property of another object
	end mouseup

Stack B
---------
	on doSomething
		--  do something
		set the dosomething_result of me to the backgroundColor of this stack
	end doSomething


That's clean... if there is any reference to any control in  
doSomething, then they will be interpreted relative to stack B, as  
expected. Note that I haven't tried that for files interacting over  
an internet connection but there is no reason to suppose it won't  
work (let me know if not).

------------------------------------------------------------------------ 
-----------------------------------------------------------------------
D. Extension to functions

You don't need this, but I add it in case this is useful to anybody.  
What if you need to pass parameters to your functions? You can use  
the custom properties to send data as well.

Stack A
---------
	on mouseup
		put the long id of stack "stackB" into tStackRef
		----
		set the p1 of tStackRef to "one"
		set the p2 of tStackRef to "two"
		----
		send doSomething to tStackRef
		wait 1 tick (I am not sure it is needed but I tend to add it)
		----
		put the dosomething_result of tStackRef  into tResult.   <---   
reading the custom property of another object
	end mouseup

Stack B
---------
	on doSomething  <--- It is not required to have the same name as the  
function
                                       --- but it is allowed and it  
makes the role of this handler easier to understand
		set the doSomething_result of me to \
                         doSomething(the p1 of me, the p2 of me)
	end doSomething
	function doSomething p1, p2
	      --  do something
              return tResult
	end doSomething

This way, you can simply directly use the function form anytime you  
need to call to it from within the same stack and you can use the  
handler form when you need to call to the function from other stacks.  
I find it easier to declare the parameters to the function this way,  
using custom properties, than using the value construct. It adds the  
cost of having to handle custom properties but custom properties  
manipulation is reputed to be fast most of the time I am making use  
of custom properties that already exist in my script anyway.

You could of course read and write custom properties from within the  
function. Personally, I prefer to completely separate the two logics.  
Handlers are used to respond to the user actions on the interface.  
Functions transform an input data into an output data and have very  
little knowledge of what exists outside them. They know only what  
they need to know to operate the transformation on the input data and  
that's it. They don't need to know where the data came from.... then  
you have the problem to handling the case where p1 and p2 have been  
defined internally, etc., etc.  reading the custom properties outside  
the function makes things a lot easier.

Best,
Marielle

On 29 Oct 2006, at 16:49, Bridger Maxwell wrote:

> Hey,
>  Is it possible to activate a function that resides in one stack,  
> and get
> the result from a different stack?  Right now I have it set up so  
> that Stack
> A gets a request for info from stack B over the Internet.  Lets  
> pretend that
> the request is "the background color of this stack".  It puts that  
> into a
> variable called vWhat.  Then it executes do ("get" && vWhat && "of  
> Stack
> B").  Then Stack A returns the data over the Internet.  This works  
> well for
> requesting properties, but I can't get it to activate a function  
> and put the
> result in the it variable.  Is it even possible?  Is there a "send"
> equivalent for functions?
>
>   TTFN
>     Bridger
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

------------------------------------------------
Marielle Lange (PhD),  http://widged.com
Bite-size Applications for Education