Escape should cancel GUI drag ops

[TheQwerty]

Currently (v9.60.0004) if you drag an item in the list, catalog, list managers, and tree, pressing escape before dropping will cancel the operation.

This is the desired behavior, but it needs extended to dragging parts of the GUI around, such as:
Moving Tabs
Moving Splitters
Resizing the IP
Scrolling the Toolbar

In addition, there's a small bug where pressing escape when dragging an item in the UDC manager or Configuration->Color Filters closes the dialog instead of (in addition to) canceling the drag.


In both cases there may be more instances than I caught, so everyone feel free to mention any I missed.

[admin]

Yes, but low prio. And, hey, I never knew that one can ESC resizing or moving a window (even in XY) in Windows -- wow.

[TheQwerty]

Yes, but low prio. And, hey, I never knew that one can ESC resizing or moving a window (even in XY) in Windows -- wow.

Yep, it's a pretty standard convention.

I think XY may be the only program I've stumbled across that doesn't obey it as I'd expect.

[admin]

Yes, but low prio. And, hey, I never knew that one can ESC resizing or moving a window (even in XY) in Windows -- wow.

Yep, it's a pretty standard convention.

I think XY may be the only program I've stumbled across that doesn't obey it as I'd expect.

But it does! (I mean resizing or moving)

[TheQwerty]

Confirming that, as of v9.60.0005, tab moving can be canceled and escape no longer closes the dialogs when canceling a drag.

Figures the one I actually found annoying (splitter movements) is of lower priority.

[admin]

Confirming that, as of v9.60.0005, tab moving can be canceled and escape no longer closes the dialogs when canceling a drag.

Figures the one I actually found annoying (splitter movements) is of lower priority.

Splitter movements are happening realtime -- this is a different situation I think: There is nothing to escape from.

[TheQwerty]

Splitter movements are happening realtime -- this is a different situation I think: There is nothing to escape from.

The way I look at it, while the GUI is updating real-time the change does not actually take until I drop the splitter, so I expect Escape to cancel the move. Or if you prefer pressing Escape should reset the splitter to the position it was at before the drag started.

WE shows the desired behavior on the splitter between the tree and list, and it too is updating the GUI in real-time.


EDIT: Change from "correct behavior" to "desired". Though it gives me the "But WE does it this way..." so it must be correct, support.