Thanks for the info.  It was very helpful.
I looked up who implements #userInterruptWatcher and InputSensor does.
I can figure out what I need to do from what InputSensor does.

Sorry for not stating my objective more clearly in my original post.
What I am trying to do is catch a user interrupt or some other
signal from the user and then shut a particular process down cleanly.
The user is able to restart the process whereupon it starts approximately
at the point it was interrupted but at a clean restart point.
What I will do now is one of your solutions. That is, generate some error when
I catch the interrupt and then catch the error using a block where I clean up
as described in the original post.  i.e.

arrange to watch for user interrupts and generate an InterruptGeneratedError
when a user interrupt is generated.
 [some code]  on:  InterruptGeneratedError  do:
        [shutdown process cleanly and restore system userInterruptWatcher].

Regards,

Ralph Boland

> Hi Ralph -

> The answer to your question depends a little on why you're trying to do
> what you're doing. Generally speaking, there's a #userInterruptWatcher
> process that waits until the interrupt semaphore is signaled and then
> does whatever it is instructed to do. It could easily interrupt the UI
> process with an exception for example, in which case your code (if run
> from the UI process) would work.

> On the other hand, if what you're really trying to do is to seal an
> image for production purposes you can just kill the interrupt watcher
> process and no interrupt handler will ever be run. Or, you can do what
> we do in our production images - use the interrupt watcher to signal the
> UI to pop up a password box which will allow you to break into the
> running app if you enter the correct password.

> So there's a bunch of options depending on what you're trying to do.

> Cheers,
>   - Andreas

> On 5/20/2010 3:10 PM, Ralph Boland wrote:
>> I would like to be able to catch a user interrupt or, if not possible,
>> some other user action like a key stroke or mouse action much like
>> one catches an Error.  Ideally my code would look something like:
>>
>> [some code]  on:  Interrupt  do:  [process Interrupt].
>>
>> Of course there is no class Interrupt and even if there was
>> my guess is that user interrupts are handled at a low enough
>> level that the above code wouldn't work anyway.
>> For example, for the code:
>>
>>    [some code]  on:  Error  do:  [process Interrupt].
>>
>> The user interrupt is generated while  "some code" is running
>> so the  "process Interrupt" code has no chance of running.
>>
>> A simple question.  I'm guessing the answer is not so simple
>> and perhaps not so safe.
>>
>> I hope others find this question interesting.
>>
>> Regards,
>>
>> Ralph Boland