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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
