Re: Call a function on another card

2017-02-24 Thread Bob Sneidar via use-livecode
Yes, but Peter has a single behavior for all his cards, but unique script local variables for each card. He wants those script local variables to be visible to his behavior. In a related note, I want to say again that properties can act as scoped variables using the method I described. So

Re: Call a function on another card

2017-02-23 Thread Richard Gaskin via use-livecode
Bob Sneidar wrote: > I did a quick little test. The card's script local variables are not > accessible from the behavior script. True, but you may not need to: each object subscribed to a behavior script maintains its own set of script-local variables. -- Richard Gaskin Fourth World

Re: Call a function on another card

2017-02-23 Thread Peter Bogdanoff via use-livecode
Thanks Bob, I’ll look at this more closely. One benefit of using custom properties rather than local variables is that I’ve seen that local variables are sometimes emptied on some script errors when working on a script. Then I have to quit and reload the stack. Peter On Feb 23, 2017, at 3:17

Re: Call a function on another card

2017-02-23 Thread Bob Sneidar via use-livecode
I did a quick little test. The card's script local variables are not accessible from the behavior script. At this point you might consider using card properties instead. This is what I have been doing. This way each card can have it's own "variables" in the form of properties. Then you can

Re: Call a function on another card

2017-02-23 Thread Bob Sneidar via use-livecode
I may be mistaken, but I think that script locals are accessible to a behavior script. If so, you could keep the script local variables in the card, and the handlers in a library or backscript. I will set up a test for that. Bob S > On Feb 23, 2017, at 14:51 , Peter Bogdanoff via

Re: Call a function on another card

2017-02-23 Thread Peter Bogdanoff via use-livecode
Bob, This is a good question. In my case, each card script has script local variables that are used only for that card. In this unusual case (I’m creating a text search method) I need to access the contents of those variables from another stack. I indeed would like to move common handlers to

Re: Call a function on another card

2017-02-23 Thread Paul Hibbert via use-livecode
> On Feb 23, 2017, at 12:32 PM, Peter Bogdanoff via use-livecode > > wrote: > > put value("myFunction(hello, world)", group "myGroup" of card "myCard") into > tResult > > I want to use a variable as a parameter instead of

Re: Call a function on another card

2017-02-23 Thread Bob Sneidar via use-livecode
When I encounter situations like these, I begin to ask myself why the handler is in a card script. If it needs to be accessible from other cards, it should probably be moved to the stack script, or put into a button and inserted into front or back. I have 3 buttons I use for this effect:

Re: Call a function on another card

2017-02-23 Thread Peter Bogdanoff via use-livecode
Yes, thank you, that works. I used: dispatch function "getPageNumber" to card "MITA" of stack "MITA" with tID What came back was in “the result” “it” contained “handled” pb On Feb 23, 2017, at 12:54 PM, Mike Bonner via use-livecode wrote: > Will this work for

Re: Call a function on another card

2017-02-23 Thread Mike Bonner via use-livecode
Will this work for you? dispatch function "myFunction" to card "myCard" put the result into tResult Parameters can also be passed using the "with" extension. Unlike the "call", "send" and "value" handlers, the parameters are sent directly to the target handler, rather than being extracted from