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