On Wed, Aug 27, 2014 at 10:42 AM, Michael Doub <miked...@gmail.com> wrote:
> The send with no time specified and dispatch, both inserts the called > hander, just below the top entry on the stack to it will be the next to > execute when the current top entry is finished. I might be misunderstanding your explanation but not sure that's correct, at least for dispatch. Reason I say that is that you can immediately check the it variable after a dispatch command to see it was handled or not. Plus, if you dispatch a function, you can get hold of the returned value in the the result variable in the next line after the dispatch command. So it seems clear the the calling handler waits (or "blocks" in my terminology) until the dispatched handler has completed before continuing. 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. 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. Pete lcSQL Software <http://www.lcsql.com> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html> _______________________________________________ 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
