Hi Larry, so the escape key handling goes like this:

1. If a dialog or flyout menu window has focus, it will close that window. If it was a modal window it will give the cancel return code value.

2. If there was no dialog to target, then if there is any active selection filter it will clear that.

3. If there was no selection filter, then if a command is running it will cancel that command.

4. If there was no command running, then if there is an object using an event loop waiting for events it will cancel that making it exit the waiting state.

5. If there was no waiting object, then if there are any selected objects it will clear the selection.

6. If there was not any object selection then it looks if any objects had edit points turned on and if so then turns them off.



So the #3 step of canceling the current running command will cause any further wait calls to return as canceled until the command has exited.

That is indeed different than the Cancel button handling, a cancel button press will only either exit the outermost waitable object if it has allowNestedCancel() set, or otherwise do a full command cancel. It does not do any of those other things that the Esc key handler does.

I will take a look at skipping step #3 in the Esc key processing if there is currently a waiter with allowNestedCancel() set on it.

- Michael

Hi Michael,

Thank you both for the detailed explanation and the time it took to offer it. I took my understanding of the function of the Enter and Esc keys from the Shortcut Keys section of the MoI Command Reference. Clearly there is much more going on "under the hood" than meets the eye!!

Your thought about conditionally skipping #3 sounds plausible & I will look forward to your investigation and decision about any changes to the Esc key processing.

--Larry