How does a command find out who called it?

Bob Sneidar bobs at twft.com
Wed Feb 1 19:43:10 EST 2012


Dispatch does not have an "in time" argument. Only send does. The other difference is that send temporarily changes the defaultStack to the one containing the called handler. Any references to "this card" or "this stack" will reference the target stack, not the stack the handler was called from. Dispatch does not do this. It can be a gotcha if you are not aware of it. 

Bob


On Feb 1, 2012, at 2:59 PM, Pete wrote:

> This is fascinating stuff.  I always wondered about the logic of sending
> something in zero seconds, now I know.
> 
> I hate to complicate things even more but how does dispatch work in this
> regard?  I've always thought of it as a replacement for send with a nicer
> syntax, but it doesn't have an "in time" clause, so.....
> 
> Pete
> 
> On Wed, Feb 1, 2012 at 2:09 PM, Ken Ray <kray at sonsothunder.com> wrote:
> 
>> 
>> On Feb 1, 2012, at 3:41 PM, Ken Corey wrote:
>> 
>>> On 01/02/2012 21:28, Ken Ray wrote:
>>>> Really? Does it matter how long it takes the handler to complete
>> execution? That is, if the rest of the handler after the "send" takes 10
>> seconds to execute, will LC wait all 10 seconds to get to the end of the
>> handler before it sends the message?
>>>> 
>>>> Just curious...
>>> 
>>> Completely depends on your code and the order in which the handler needs
>> information.
>> 
>> Actually I just tested it… as long as the code following the "send in
>> time" message doesn't allow for any idle time, and the amount of time that
>> you are "sending" in is less than the time for the code to process, it will
>> wait until the handler is done before it sends.
>> 
>> The bottom line is that the "send <msg> in <time>" will execute <msg> as
>> soon as it gets an idle moment, so long as that idle moment is greater than
>> or equal to <time>.
>> 
>> So:
>>    send "hello" to me in 3 seconds
>> 
>> will start counting down the 3 second timer on the message immediately.
>> When the 3 seconds has elapsed, if there is not an idle moment, it will
>> wait until there is one. So if you execute this "send" and then have 2
>> seconds of code that occurs after the "send", you'll get the message 3
>> seconds after the "send". But if you have 10 seconds of code that occurs
>> after the "send", you'll get the message after all that code finishes (10
>> seconds after the "send").
>> 
>> This is why "send <msg> to me in 0 secs" will make it appear to execute at
>> the end of a handler; so long as there are no statements that will give up
>> idle time (like "wait 0 milliseconds with messages"), LC is kept busy until
>> the end of the handler, at which point it executes <msg>. But if you *have*
>> a "wait 0 milliseconds with messages" (or equivalent) in your code, as soon
>> as it hits that, your <msg> will trigger.
>> 
>> Just clarifying this for anyone who cares…
>> 
>> ;D
>> 
>> Ken Ray
>> Sons of Thunder Software, Inc.
>> Email: kray at sonsothunder.com
>> Web Site: http://www.sonsothunder.com/
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
> 
> 
> -- 
> Pete
> Molly's Revenge <http://www.mollysrevenge.com>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list