send ___ to me in ___ sec

[Dar Scott]

On Tuesday, April 23, 2002, at 11:28 PM, J. Landman Gay wrote:

> I think there may still be some confusion about this. Pending messages
> contain only those messages that you decide your scripts should insert,
> which you do by using the "send...in <time>" command.

Pending messages contain those sent by "send ... in <time>" AND 
some Revolution
messages such as socketClosed.  (I haven't gotten into externals, 
but I wouldn't be surprised if they can insert into pending 
messages.)


> There is no need ever to "send in 0". Simply issue the command. These
> two lines are equivalent:
>
>    send "myHandler" to me in 0
>    myHandler

Those are not quite equivalent.  I think you mean these two are:

     send "myHandler" to me
     myHandler

This one...

     send "myHandler" to me in 0

...will be executed after any ready messages in pending messages.  
Also, according to the TD, no errorDialog message is sent upon 
errors in myHandler.

This form is handy for messages generated by a control or group 
that may not be handled in all places that it is copied to.  Also, 
you can test out the control or group before copying it to 
destination cards.  Just as one does not have to script a handler 
for socketClosed, the card and stack that use groups or controls 
that "send ... to me in 0" don't have to define them.


> Adding the "send" syntax just makes scripts harder to read and
> complicates the pending messages queue. Unless there is a reason you
> want to track that particular "myHandler" instance in the queue (can't
> think of a reason why you'd need to though,) there is no reason to
> specifically "send" it. This is valid, and normal, syntax:
>
>    on mouseUp
>      myHandler
>    end mouseUp
>
> (But maybe you know that and I missed something.)

I do know that, though that may have been hard to see.  I was 
addressing the problem of executing a handler right after all those 
currently in pending messages.  I think that is what was asked for 
though it may not be what was needed.  Perhaps you understood the 
question better than I and missed the direction I took because of 
my erroneous understanding.

>
> Rev sends messages in the same order as events happen. Most events
> generate specific  and predictable message sequences -- for example,
> clicking a button generates:
>
>   mousedown
>   mousestilldown -- a few, not sure how many; in HyperCard the 
> minimum is 3
>   mouseup -- if the mouse is still in the object, or,
>   mouserelease -- if the mouse is not still in the object
>
> Other events generate other predictable sets of messages, always in the
> same order.
>
> If you have messages waiting in (your private) pendingMessages queue,
> they are sent at the appropriate time and are inserted into the normal
> stream of system messages whenever they come due. Your private pending
> messages are time-based rather than event-based. They just get stuck
> into the stream as needed.

This may be misleading.  It seem that ready messages in the pending 
messages will be executed before any messages that might be 
generated by events even if event times mix with due times in the 
pending messages.  At least that is the way it is on my OS X.

It is even more complicated.  Suppose a handler takes a long time 
to execute.  (Bad style, normally, but suppose.)  Suppose some 
messages in pending messages come due and some mouse events come in 
during this execution.  After the handler completes then the due 
(ready) messages are executed and then, it seems in my scripts, 
only one message from events that came in, the one for the first 
event.  At least for mouseDown and mouseUp, the latter is lost.

Dar Scott