Re: 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