wait for messages

[David Vaughan]

OK, I've waited a bit for a Transcript guru to answer Bob's questions 
(in shortened form below) but nothing has clarified this so far. So I 
tried a couple of experiments myself, effectively replicating Bob's 
results. These are two of my tests:
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?
>
> Is there a way to get a message trace in general?  That would be 
> extremely useful.
Devin Asay asked for a Message Watcher today. I didn't use it much in HC 
but it would certainly have been useful here.
>
> 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
>  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3524 bytes
Desc: not available
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20020225/f74ef6de/attachment.bin>