Although not generally recommended, there are circumstances when you might need to use the Escape key to interrupt your wimp application in much the same way as Escape was used to stop old single-tasking Beeb programs - for example, to halt an occasionally-used computation intensive single-tasking procedure.

In such a situation it may be more convenient to explicitly re-enable the Escape mechanism, rather than directly scan Escape as for any other key.

If you need to do this you must make sure it is always disabled again before you next call Wimp_Poll, to avoid affecting the behaviour of other applications. However, as long as you comply with that requirement, all else should be well.

Escape can be enabled with OS_Byte 229, by passing r1=r2=0, and disabled with arguments r1=255, r2=0.

I tried this in a C application a while ago, and it didn't seem to work. It took me, dolt that I am, two months to figure out that it had in fact enabled escape, but this was still being ignored by my application, as Acorn's RISC_OSLib wimpt_init function registers its own handlers for all signals within the C environment, including Escapes.

In the specific case of Escape, the wimpt handler does nothing, other than re-register itself, presumably as a safeguard to ensure Escapes are ignored should another application incorrectly enable them across a Wimp_Poll call.

So if you're writing in C and use Acorn's wimpt_init, to receive Escapes you will need to both enable them, via the OS_Byte call, and register a suitable signal handler using signal(SIGINT, handler), where handler has prototype void handler(int sig).

Use SIG_DFL as the handler if you just want to reset it to the default used prior to calling wimpt_init - the one which produces the interrupt received from user - program terminated message followed by program termination, whenever Escape is pressed.