Should "dispatch" be extended for timers?
Earthednet-wp
prothero at earthednet.org
Wed Aug 27 13:10:55 EDT 2014
I've wondered what, specifically, "blocking" means. Does it mean that there are no idle messages sent? What is being blocked?
Bill
William Prothero
http://es.earthednet.org
> On Aug 27, 2014, at 8:16 AM, Bob Sneidar <bobsneidar at iotecdigital.com> wrote:
>
> You cannot dispatch in time. But you can send in time. If you:
>
> send doSomething to me in 0 seconds
> do someotherthingsfirst
>
> then someotherthingsfirst will run and anything else that comes after it. doSomething will run the next idle message.
>
> Bob S
>
>
>> On Aug 27, 2014, at 07:46 , dunbarx at aol.com wrote:
>>
>> Richard.
>>
>>
>> When you say "send" is blocking, in what way? Is this really any different that calling any handler? For example:
>>
>>
>> on mouseUp
>> doSomething
>> end mouseUp
>>
>>
>> on MouseUp
>> send "doSomething" to this card
>> end mouseUp
>>
>>
>> Can you explain the difference?
>>
>>
>> Craig
>>
>>
>>
>> -----Original Message-----
>> From: Richard Gaskin <ambassador at fourthworld.com>
>> To: use-livecode <use-livecode at lists.runrev.com>
>> Sent: Wed, Aug 27, 2014 10:18 am
>> Subject: Re: Should "dispatch" be extended for timers?
>>
>>
>> Peter Haworth wrote:
>>
>>> Sounds like a great idea to me. I seem to remember that one of
>>> dispatch/send is blocking and the other isn't. Could that be a
>>> possible reason for the lack of "in" with dispatch?
>>
>> Both are blocking when called immediately; "send" can become on-blocking
>> by specifying a later time to send the message.
>>
>>
>> dunbarx wrote:
>>
>>> "Send' can, er, send parameters as well as a command. In a button
>>> script:
>>>
>>> on mouseUp
>>> send "putArg" && random(99) && random(99) && "XYZ" to me in 5
>>> end mouseUp
>>>
>>> on putArg var
>>> put var
>>> end putArg
>>>
>>> You get pairs of random numbers and the text as well. All parameters
>>> come across as a batch.
>>>
>>> Or you can separate in the usual way:
>>> on mouseUp
>>> send "putArg" && random(99) & "," & any char of "ABCD" to me in 5
>>> end mouseUp
>>>
>>> on putArg var,var2
>>> put var2 --or the first one or both
>>> end putArg
>>
>> Yes, both "send" and "dispatch" allow passing arguments, but as we saw
>> with yesterday's forum post it seems unintuitive to have to put quotes
>> around things that aren't strings, making "dispatch" feel more natural.
>>
>> Of course in a certain Zen sort of way even variable names are
>> technically strings on some level, but having to quote them to pass them
>> with "send" is something I see a lot of newcomers guess wrong.
>>
>> FWIW I submitted a request to have "dispatch" extended with "in" for timers:
>>
>> <http://quality.runrev.com/show_bug.cgi?id=13287>
>>
>> --
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> ____________________________________________________________________
>> Ambassador at FourthWorld.com http://www.FourthWorld.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
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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