> From: Peter Haworth > > I think send works the same way if it has no time specified. > According to > the dictionary, a send with no time executes the "sent" handler > immediately, then execution of the current handler continues. > With a send > in time, the current handler finishes executing before the > "sent" handler > is started.
And if you want nonblocking operation with no delay, you specify a zero time limit. > Back to the original suggestion, I still think adding an in time to > dispatch would be a good idea. I'm just not sure how the > ability to use the > it and result variables after a dispatch with an in time would work. I think the purpose of "dispatch" is to report if/how the message is handled, which implies blocking. I don't see what a dispatch with a time limit would accomplish that can't be done with a "send". It's possible that "dispatch" skips over the combining of the message and arguments into a single string, and then breaking them apart again. On the other hand, it's possible that the internal data structure that holds a message in the timer list only stores a single string anyway, in which case "dispatch" with a time limit would have no advantage at all over "send" with a time limit. -- Ciao, Paul D. DeRocco Paul mailto:pdero...@ix.netcom.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
