How does a command find out who called it?

[Andre Garzia]

On Wed, Feb 1, 2012 at 10:33 PM, Phil Davis <revdev at pdslabs.net> 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

OMG!!!! We can build schedulers!!!! =)


>
> 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



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.