like pass, but without ending the handler

[Dave Cragg]

On 1 Mar 2007, at 09:26, Dick Kriesel wrote:

> On 2/28/07 3:27 PM, "J. Landman Gay" <jacque at hyperactivesw.com> wrote:
>
>> The important part is the "wait <time> with messages", which  
>> allows user
>> input to occur simultaneously. That will allow you to put in a "stop"
>> button. But while "wait with messages" does allow the messages to
>> happen, it does not allow them to be acted on. They will pile up in a
>> queue until the loop is exited. Some of them, anyway. I think some  
>> were
>> just lost.
>
> Jacque, could you please clarify this?  What's the difference between
> happening and being acted on?  If Rev loses messages, I'd like to
> understand, so I don't write code that's likely to fail and that  
> cannot be
> debugged.

I don't know of any case of messages being lost. Generally, the  
approach outlined by Mark works fine. But there are a couple of  
things to watch out for.

1.  Be careful that you can't re-enter the original script. You could  
do this by disabling the button (if that's what's used) or setting a  
flag of some kind. (The example below disables the Start button.)  If  
you don't do this, it's hard to predict what will happen. Try  
disabling the "disable me" line below, and then click the Start  
button a few times. And then the Stop button.

If you do want the process to be re-enterable (doing many things in  
parallel), you'll need to keep track of the different "threads".  
Perhaps by using an array of some kind. (libUrl does this kind of  
thing with mutiple load requests.)

2. Be careful of placing other "wait .. with messages" commands  
before an earlier one has been "released". Again, in the example  
below, try uncommenting the marked line in the "processToWaitFor"  
handler. You'll see that it stops the repeat loop in mouseUp  
handler.  This can be a hidden problem if you bundle something in a  
library that runs asynchronously, and uses a callback to indicate it  
has finished.


## EXAMPLE based on Mark's earlier example, two buttons named "Start"  
and "Stop"

##script of button "Start"

local sProcessDone, sMessageID

on mouseUp
   disable me ## Point 1 stop re-entry
   put false into sProcessDone
   send "processToWaitFor" to me in 0 milliseconds

   put 0 into tCounter
   repeat until sProcessDone or tCounter >= 100
     wait for 100 milliseconds with messages
     add 1 to tCounter
     put tCounter
   end repeat
   put "DONE"
   enable me ## OK now
end mouseUp

on processToWaitFor
   ## simulated backgroun process
   send "processFinished" to me in 10 seconds
   put the result into sMessageID
   ##wait until sProcessDone with messages ## Point 2 CAREFUL

end processToWaitFor

on processFinished
   put true into sProcessDone
end processFinished

on stopButtonClicked
   cancel sMessageID
   put true into sProcessDone
end stopButtonClicked

##script of button "Stop"

on mouseUp
   send "stopButtonClicked" to button "Start"
end mouseUp

Cheers
Dave