On Sat, Jan 7, 2012 at 8:42 AM, Oliver Sims <
> Using the new dragNdrop.rex program in ooRexx\samples\oodialog\mouse, I
> drag an item from the list and, still with Button1 held down, I hit Esc.
> I expect the drag to be cancelled. Instead, the dialog closes. I expected
> the drag to be cancelled, not the dialog. Should I revise my expectation?
Hi Oliver, I guess revise the expectation, or do some extra work.
The MSDN documentation in several places mentions that the escape key
cancels a drag operation and so I've been throwing that into the
discussion. But, I had not actually tested it myself, and the MSDN
documentation is sometimes vague.
So, in testing it, it appears that at the very least the Esc gets passed on
to the dialog manager, which then closes the dialog.
The key in deciding what to do, would be what your users expect. I myself
have used Windows for pretty long now, and I never would have *expected*
that using the escape key would cancel a drag operation, until I read it in
the MSDN documentation.
If it is the expected behavior then the thing to do would be to swallow the
escape key when you are in the midst of a drag operation. Normally, it is
pretty hard, in ooDialog, to tell if you get cancel() because of the escape
key or the user pressing your cancel button.
But here, you can tell if you are in the middle of a drag operation or
not. (At least I assume you have to know you are in the middle of a drag
operation because I don't see how to code drag and drop without keeping
track of the fact you are dragging.)
For example, in the sample program I did, you could add a cancel()
over-ride method. Then in cancel check if you were in the middle of a drag
and just return. Something like:
::method cancel unguarded
if dragging then return 0
-- Not dragging do whatever ....
It may be that what the MSDN documentation means is, we (Microsoft) want
users to expect that the escape key cancels a drag, so be sure you code
your applications that way.
An interesting experiment would be to try and see if you get a LBUTTONUP
event when the escape key is used.
The sequence from the OS could be post LBUTTONUP to window, post ESC key to
dialog. Or, it could just be post Esc key to dialog. Originally when I
read it, I assumed that MSDN meant that pressing the Esc key in the middle
of dragging generated a LBUTTONUP event *rather* than an Esc Key event.