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