Exit Repeat

[Geoff Canyon]

On Mar 20, 2006, at 1:47 AM, Chipp Walters wrote:

> put the executioncontexts

Thanks, Chipp! Now we have a puzzle (I think)

I have a button with this script:

on mouseUp
   set the canInterrupt of this stack to true
   repeat with i = 1 to 1000
     wait 0 ticks with messages
     put i
   end repeat
   set the canInterrupt of this stack to false
end mouseUp

The stack has this script:

on escapeKey
   if the canInterrupt of me then
     put the executioncontexts
     set the canInterrupt of me to false
     exit to top
   end if
end escapeKey

These are both copied from Mark Smith's example. Clicking the button  
starts counting up in the message box. Pressing the escape key stops  
the counting and puts this:

stack "Navigator",escapeKey,4

Note that the script of the button is not listed. I think that is  
correct, because the escapeKey message was generated from the key  
being pressed -- the fact that the mouseUp handler had to yield time  
to let it happen is irrelevant.

The documentation says about exit to top:

      Halts the current handler and all pending handlers.

I checked to be sure, and send...in messages are not terminated. The  
documentation goes on to make this clearer by saying:

      If the current handler was called from another handler, the  
calling handler
      is also halted. Other messages that depend on the same action  
are also
      suppressed: for example, if an exit to top control structure is  
executed in
      a closeCard handler, the corresponding openCard message is not  
sent to the
      destination card.

I _guess_ that could be construed to apply in this case, but I think  
the docs should be explicit. Frankly, this behavior seems backward to  
me. What does everyone (anyone) else think?

Although it is convenient in this case, it seems wrong to me that  
exit to top in the escapeKey handler above also terminates the  
mouseUp message.

gc