I “improved” my script just to check that each time the handler is called it still gets its own local variables:
on oneOrTwo local tCount add 1 to tCount put "one" && tCount & return after Field "Field" wait 50 with messages put "two" && tCount & return after Field "Field" end oneOrTwo As you would expect, if you make tCount script local rather than handler local, it is “shared” between the “pseudo-simultaneously” running handlers. Regards Peter > On 23 Jan 2015, at 12:42, Peter W A Wood <peterwaw...@gmail.com> wrote: > > Jacque > > I believe that the engine can start processing the second call before the > first is finished after I did a little experiment: > > One card, button1, button2 and a field > > Both buttons with this script: > > on mouseUp > oneOrTwo > end mouseUp > > A card script with > > on oneOrTwo > put "one" & return after Field "Field" > wait 50 with messages > put "two" & return after Field "Field" > end oneOrTwo > > Clicking on the buttons in quick succession gives one, one, two, two. > > I found out that you don’t even need two buttons. Hitting one button twice > quickly will give the same effect. > > Regards > > Peter > >> On 23 Jan 2015, at 11:26, J. Landman Gay <jac...@hyperactivesw.com> wrote: >> >> Suppose I have a long handler that includes a few "wait with messages" so >> that users can continue interacting with the stack while it runs. The user >> does something that calls the long handler while it is still running from a >> previous instance. Assume there is no flag in the script to prevent that. >> >> Does the engine queue the second call until the long handler finishes, and >> then send the message from the second call (serial responses)? >> >> Or does the engine run two instances of the long handler simultaneously? If >> so, what happens to the values of the variables? >> >> Or something else? >> >> I've never allowed this to happen before but I find myself in a position >> where simultaneous calls would be the best way to handle things. >> >> -- >> Jacqueline Landman Gay | jac...@hyperactivesw.com >> HyperActive Software | http://www.hyperactivesw.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
