The scheme described in the other post is only as responsive as the frequency at which system events are processed.
If you have anything happening in any code anywhere in your process that takes a long time, you need to hack in calls to process system events, otherwise the panel callback won't get executed and your keyboard event won't be recognized.
This is unfortunate. What you really want is some way to absolutely, positively ensure a programatic response to a keyboard event regardless of what your code might be doing at the moment, and you'd like for this to happen without cluttering your code up with lots of ProcessSystemEvents calls. Perversely, even lots of processsystemevents calls won't help with very situation in which you need the quick response the most - a hardware or software anomaly has hung up your system and your expensive unit under test is burning up.
I've used a separate process, with a single small panel with a single "ABORT" command button that runs at high priority and simply monitors the ABORT key every hundred milliseconds or so to see if it's been committed. The OS will ensure the abort process runs regardless of what's happening in the main program as it's higher priority than your main program. When there's an event, the abort process can do whatever's needed to safe the system. This could include signalling the main process (but that begs the question of the main process servicing an event related to the signal) or aborting the main process. Contention for resources between the two processes would have to be provided for (e.g. both processes trying to access a power supply - the main to turn it on, and the abort to turn it off). If the main process has been aborted this wouldn't be an issue.
Menchar
