Hi Michael,

The changes made in the Sept 10 beta definitely help in that pressing Esc no longer throws an exception.

> Update Esc script cancelling
> Use different method to determine time since last wait for event. The previous method of watching calls to
> WaitableObject::waitForEvent() is not good because there are other kinds of event loops that do not go through
> WaitableObject, like modal dialogs or combo box dropdowns. The new method should handle all types of event loops.

I am seeing something puzzling though: pressing Esc acts differently than clicking on Cancel. I tend to use Esc rather than Cancel and would like Esc to behave the same as Cancel. Admittedly I do not have a good handle on the event structure being used, but I'm attempting to write a script which behaves consistently with the rest of the MoI. I believe this was happening with the last beta, but I was hung up on the exceptions being thrown.

My Coordinates script has two pointpicker loops (or phases of operation): first, picking the leader arrow tips in doCoordinates(), and second, picking the leader points in coordinateLeader(). Although it is two functions, it is in effect a nested loop and makes use of pointpicker.allowNestedCancel() to allow more granular control over removing just the current objects rather than all objects created during the command execution.

If I click on the Cancel button in the inner phase, that phase cleans up and goes back to the outer phase which allows another leader arrow to be picked. If I press Esc instead, the inner phase cleans up, returns to the outer phase, but another cancel event is magically generated causing the command to exit. The following traces illustrate the difference & the Prompt/Action pairs explain how to reproduce the behavior.

Clicking on the Cancel button during the "Pick next leader point" (inner) phase:

/Users/michael/src/moix/moi_lib/Init.cpp 310: Moi starting up
MoI version: 4.0 Beta Sep-10-2020
1ms: doCoordinates()
Prompt: “Coordinates options"
Action: Click Done
Prompt: “Pick leader arrow tip"
Action: Pick point
3444ms: doCoordinates() event: finished
3444ms: coordinateLeader()
Prompt: “Pick next leader point"
Action: Click on Cancel button
6930ms: coordinateLeader() canceled: cancelbutton
6930ms: coordinateLeader() event: cancel
Prompt: “Pick leader arrow tip”
Action: Click on Done button
8433ms: doCoordinates() event: done

Pressing Esc key during the "Pick next leader point" (inner) phase:

/Users/michael/src/moix/moi_lib/Init.cpp 310: Moi starting up
MoI version: 4.0 Beta Sep-10-2020
1ms: doCoordinates()
Prompt: “Coordinates options"
Action: Click Done
Prompt: “Pick leader arrow tip"
Action: Pick point
3194ms: doCoordinates() event: finished
3195ms: coordinateLeader()
Prompt: “Pick next leader point"
Action: Press Esc key
9764ms: coordinateLeader() canceled: escape
9764ms: coordinateLeader() event: cancel
9806ms: doCoordinates() canceled: cancelbutton     <<< extra event is being magically generated
9806ms: doCoordinates() event: cancel

Code is attached for reference.

--Larry

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