How does a command find out who called it?

[Devin Asay]

I'm pretty sure Jacque's time warp stack already uses this!

Devin

On Feb 1, 2012, at 5:33 PM, Phil Davis wrote:

> Here's a related tidbit I learned from Dar Scott (and who else would think of it?  ;-)
> 
> If you have several pending messages and you want to send the next one to the front of the pendingMessages, you can:
> 
> send "doUrgentStuff" to me in -3 seconds
> 
> You can use a negative time!
> 
> Phil Davis
> 
> 
> 
> On 2/1/12 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
>>> 
>>> 
>> 
> 
> -- 
> Phil Davis
> 
> PDS Labs
> Professional Software Development
> http://pdslabs.net
> 
> 
> _______________________________________________
> 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

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University