Think of script execution like a slide at the playground. Only one kid can go down the slide at a time, and each kid has to get off the slide before the next kid can go. However you can queue up kids on the platform at the top. You can even tell one kid to go before another that is already on the platform, because the platform at the top of the slide is big enough to hold a number of kids.
Okay, the analogy is getting out of hand. So if you had send in 2 seconds followed by send in 0 seconds, the second one would go first IF it happened before 2 seconds was up. Otherwise it would go second because it was queue'd second and the first send's time delay already expired. See? Of course, my normal disclaimer of, "I might be wrong about this" applies here, but I think this is how it works. In the final analysis, only use send in time if you need a handler to fire after the first is done. Otherwise just call it in line after whatever needs to happen first has happened, and let the single threading of the LC engine keep things orderly for you. IMHO of course. Bob On May 10, 2012, at 5:01 PM, Nicolas Cueto wrote: > Solved it! > > It seems the problem was related to "send in 0 milliseconds". In > essence, HANDLER 1 before exiting would call HANDLER 2, and then > HANDLER 2 would before exiting do two "send in 0 milliseconds" to > HANDLERS 3 & 4. > > During debugging, when I inserted a "wait 50 milliseconds with > messages" at the end of HANDLER 2, the script worked. > > So, I then tried it without the "wait" after first replacing the "send > in 0 milliseconds" with explicit calls to HANDLERS 3 & 4 within > HANDLER 2. That worked too. > > > > The LC doc's entry for "send" states: > > "If you use the send in time form of the send command--even if you > specify a time of zero seconds--the current handler finishes executing > before the message is sent." > > Am I wrong to understand that, in my situation described above, the > "current handler" would be HANDLER 2? And, if there's 2 "send in 0" > statements, in what order do they get triggered? > > > Very relieved to be done with this problem! > > Cheers. > -- > Nicolas Cueto > > > > On Fri, May 11, 2012 at 7:13 AM, Peter Haworth <[email protected]> wrote: >> It's on the same card. >> Pete >> lcSQL Software <http://www.lcsql.com> >> >> >> >> On Thu, May 10, 2012 at 2:36 PM, Bob Sneidar <[email protected]> wrote: >> >>> Hmmm... I seem to recall a similar issue. If you are not on the card that >>> contains the "abc" button, then LC will not know about it yet. Try changing >>> your script to refer to the button as button "abc" of card "<thecardname>" >>> and see what happens. >>> >>> Bob >>> >>> >>> On May 10, 2012, at 12:37 PM, Mark Wieder wrote: >>> >>>> Peter Haworth <pete@...> writes: >>>> >>>>> >>>>> Well, there is one thing worse that that - somethig that works in the >>> IDE >>>>> but not in a standalone. >>>> >>>> PowerDebug is the only way to debug running standalones interactively. >>>> >>>>> I have a situationlike that right now where a simple "send mouseUp to >>>>> button "abc" where the sender is on the same card as button "abc". >>> Works >>>>> fine in the IDE but fails in a standalone, with the error message "Hint" >>>>> being the button "abc". >>>> >>>> Could there be an error in the mouseUp handler in the button? What's the >>> error >>>> code number? The button is named "abc" without spaces or quotes? Can you >>> tell if >>>> it's the send command or the mouseUp handler that's at fault? >>>> >>>> -- >>>> Mark Wieder >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ 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
