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 <bobsnei...@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 , dunb...@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 <ambassa...@fourthworld.com> >> To: use-livecode <use-livecode@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 >> ____________________________________________________________________ >> ambassa...@fourthworld.com http://www.FourthWorld.com >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode