Mark.
I know that. I know that "wait" is blocking without the "with messages" part. I found this a terrific and profound improvement over HC. I've been around the block, you know. What I am missing, though, is what happens during the time a script has finished, and a new message is sent "in time". I see no blocking intrinsic to any portion of such a construct. Two buttons. In one, place on mouseUp put random(99) if the optionKey is down then exit to top send "mouseUp" to me in 1 second end mouseUp In btn 2: on mouseUp set the loc of me to the mouseLoc end mouseUp Press button 1. You get a second counter. Any time you wish, you may click on the other button and watch it jump to the mouseLoc. As advertised, and as i understood it. In original sample script, why isn't the secondary message caught by the working handler while it is running, as opposed to while it is under the control of the debugger? It does not matter if I send the message back in a longer time. So to simplify, two more buttons. In the first: on mouseUp showRandoms 3 end mouseUp In the second: on mouseUp showRandoms 0 end mouseUp in the card script: on showRandoms var put random(99) if var = 0 then repeat for each line tLine in the pendingMessages cancel item 1 of tLine end repeat exit to top end if send "showRandoms" && 3 to this card in 60 end mouseup Does the existence of a pending message block a new call to that very handler from another source? The stop works if the code runs as shown. It fails if the repeat construct is commented out. That is what I am trying to understand. Craig -----Original Message----- From: Mark Wieder <mwie...@ahsoftware.net> To: use-livecode <use-livecode@lists.runrev.com> Sent: Tue, Oct 2, 2012 1:52 pm Subject: Re: Finally found one. Craig- > I thought of that, but believed that the "send in time", where I even increased the time value to, say, 100 ticks, would be more than enough to allow the engine to "rest". It's not a matter of giving the engine time to "rest". See below. > I see clearly what "wait with messages" does. No, I do think you're missing the point. It's the "with messages" part that's important, not the "wait" part. It doesn't matter how long you wait - if you omit the messages part the engine still won't be looking for other events. "With messages" says "look around and see what other messages may have been triggered before continuing". As in, someone might have clicked a button. Or a message may have come in from another control. Or another timer has expired. Or... > But I am trying to avoid "wait" in general Waiting for 0 milliseconds is essentially not waiting. It just gives us something to tack the "with messages" part onto. So don't be afraid of waiting for no time. The overhead of checking for messages will take up more time than the wait statement and you won't even notice it. -- Mark Wieder mwie...@ahsoftware.net _______________________________________________ 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