In the stack I put this idle handler (oh shame!)
on idle
global gFrog
add 1 to gFrog
end idle
and in a button this script:
on mouseUp
global gFrog
put zero into gFrog
put empty into field 1
put empty into field 2
repeat with i = 1 to 50
wait for messages
put i & comma after field 2
put gFrog & comma after field 1
end repeat
end mouseUp
The result was that messages continue to flow during the repeat loop, but only slowly, a shade faster than the idle message (and therefore it was not the idle message, as promised by the documentation). If I moved the mouse during the loop then it accelerated dramatically.
I ditched the idle script and changed the button script to:
on mouseUp
put empty into field 1
put empty into field 2
put the ticks into tickTime
repeat with i = 1 to 50
wait for messages
put (the ticks - tickTime) & comma after field 2
put the ticks into tickTime
end repeat
put average(field 2) into field 1
end mouseUp
Being careful not to move the mouse, I clicked the button and saw tick delays of 6,17 and 32 for the first three instances after which it settled down to 30 tick intervals with the occasional 29 (average 29 ticks). Wriggling the mouse accelerated the loop to 1-2 tick delays.
So, part of the answer seems to be that "wait for messages" will wait up to 30 ticks for a message and then continue processing anyway. In fact, it may wait only 6 or so ticks on the first pass. This is not what the documentation says, and also leaves the value of the construct rather uncertain.
Incidentally, in a separate test I found that waitDepth remained at 1 before, during and after a loop such as the above. This seems correct if it means that only the mouseUp handler was executing.
Is there any further enlightenment that can be offered on the "Wait for messages" command please? I am comfortable at the moment with the "with messages" form. Unless further experiments have offered him enlightenment, Bob is probably still pretty curious too.
regards
David
On Monday, February 25, 2002, at 01:00 , Bob Rasmussen wrote:
Can anyone give me some insight about the "wait for messages" command? Is there a way to see what messages are causing "wait for messages" to stop waiting?Devin Asay asked for a Message Watcher today. I didn't use it much in HC but it would certainly have been useful here.
Is there a way to get a message trace in general? That would be extremely useful.
What does the following note in the "waitDepth" entry of the Transcript Dictionary mean?
"The wait for messages form of the wait command allows Revolution to respond to
messages and execute handlers while waiting."
Speaking of "waitDepth", if there are multiple waits pending, in what order to they resume? Last first? Last last? Unspecified?
Does a message resume all waiting handlers, or just the next in line? I'm guessing all, if the documentation is correct, but the resumption order question still pertains.
I've looked in the Revolution stacks for examples of "wait for messages". They all look something like this:
. . .
repeat while someStatus is empty
wait for messages
end repeat
