wait for messages

[David Vaughan]

Bob

I think we can now answer some of your questions:

> Why should it have worked the first time, but not subsequently?
In my experience, it never waited (in the indefinite sense) and I have 
no idea why it waited for you even once. Your system had some 
coincidental activity that slowed it down at the critical moment?
>
> Are there messages a script can never see (or that bypass the usual 
> message hierarchy) that, nevertheless, satisfy the wait condition of 
> "wait for messages"?
I doubt it. It just seems to time out after a period up to 500ms.
>
> Is there a way to see what messages are causing "wait for messages" to 
> stop waiting?
Thanks to Richard Gaskin's Umbrellaman, just posted, I checked and there 
are no known messages causing it to time out. It just stops, as I said 
above.
>
> Is there a way to get a message trace in general?  That would be 
> extremely useful.
Indeed it is. Check Richard's post and stack.
>
> 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."
As I said in my earlier post on this, "wait N time" stops other handlers 
while it waits whereas "wait for messages" allows them to execute while 
it waits up to half a second, and "wait N time with messages" waits that 
time while allowing other events and handlers to execute.
>
> Shouldn't that be "... with messages form ..."?
...well, that is more useful, I think.
>
snip

> Speaking of "waitDepth", if there are multiple waits pending, in what 
> order to they resume?  Last first?  Last last?  Unspecified?
It appears to me that the waitDepth shows the number of handlers 
executing, not the messages waiting. This is pretty much what the 
documentation says. The tests above (one button) showed a waitDepth of 1 
while the test below (used two buttons, waiting one while pressing 
another) showed a waitDepth of 2.
>
> 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
>     . . .
>
> Why wasn't the command "wait while someStatus is empty with messages" 
> used instead?
Can't answer for why, but...
>   Are these equivalent? 
...they are not equivalent. The "wait while...with messages" construct 
will barrel along handling all messages and executing all handlers other 
than the one with the wait statement, until the wait is satisfied when 
it, too, will resume. A "wait for messages" form will continue execution 
of that handler after 500ms even where nothing else has happened.
> One potential difference I see is that the repeat loop won't pause for 
> messages if the loop condition is false, while "wait while" might 
> require at least one message to proceed, even if the condition is 
> already false.  Is that right?
No, it isn't. The condition is checked immediately and, if false, 
processing continues.
>
> Sorry for being longwinded, but a detailed section in the documentation 
> on execution order, in the presence of waits and sends, would be 
> welcome, and I'm hoping all these questions prompt some of its contents.
Execution order is the usual chronological order of events (and their 
messages). It is not mucked around by wait except to the extent that a 
script is halted in certain usages or that other handlers can execute 
during that time, but, again, in their natural order.
>
All my comments are research-based, not guru-given, so forgive me for 
any errors, omissions or lack of clarity. My tentative conclusion, 
incidentally, is that "wait...with messages"  is great and "wait for 
messages" is useless. Whether or not the last is true, the documentation 
on it needs improvement.

regards
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4245 bytes
Desc: not available
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20020225/6abf6f47/attachment.bin>