Finally found one.
dunbarx at aol.com
dunbarx at aol.com
Tue Oct 2 19:49:03 CDT 2012
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
if the optionKey is down then exit to top
send "mouseUp" to me in 1 second
In btn 2:
set the loc of me to the mouseLoc
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:
In the second:
in the card script:
on showRandoms var
if var = 0 then
repeat for each line tLine in the pendingMessages
cancel item 1 of tLine
exit to top
send "showRandoms" && 3 to this card in 60
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.
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.
> 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.
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
More information about the use-livecode