Finally found one.

[dunbarx at aol.com]

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 <mwieder at ahsoftware.net>
To: use-livecode <use-livecode at 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
 mwieder at ahsoftware.net





_______________________________________________
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode