How does a command find out who called it?
rdimola at evergreeninfo.net
Wed Feb 1 19:53:41 CST 2012
Sweeeeeeet!!!!! send in 0 seconds and send in -3 seconds open up so many
possibilities. The message path now starting to gel. Done a lot of RT
programming in the past. This opens up LC to a lot of things I want to do.
THANKS again folks! Keep it coming I'm hungry.
Evergreen Information Services
rdimola at evergreeninfo.net
From: use-livecode-bounces at lists.runrev.com
[mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Phil Davis
Sent: Wednesday, February 01, 2012 7:33 PM
To: How to use LiveCode
Subject: Re: How does a command find out who called it?
Here's a related tidbit I learned from Dar Scott (and who else would think
If you have several pending messages and you want to send the next one to
front of the pendingMessages, you can:
send "doUrgentStuff" to me in -3 seconds
You can use a negative time!
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.....
> 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
>> 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
>> you are "sending" in is less than the time for the code to process, it
>> 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
>> or equal to<time>.
>> 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
>> the end of a handler; so long as there are no statements that will give
>> idle time (like "wait 0 milliseconds with messages"), LC is kept busy
>> the end of the handler, at which point it executes<msg>. But if you
>> a "wait 0 milliseconds with messages" (or equivalent) in your code, as
>> as it hits that, your<msg> will trigger.
>> Just clarifying this for anyone who cares.
>> 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:
Professional Software Development
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
More information about the use-livecode