guarding against double-clicks in file dialogs

wxPython Users
1

I remember bringing this up a long time ago, but I can't find a solution in
any of my code examples, so here goes again.

The problem is that, at least on Windows, if you double-click on a filename
in an open file dialog, then the file dialog closes, but extra mouse events
are sent to the window underneath the dialog where you double-clicked.
Specifically the app gets a single wxEVT_ENTER_WINDOW event, followed by a
number of wxEVT_MOTION events where LeftIsDown is true (aka a drag event).
This is very easy to see with the Message Watcher in PythonCard, but you'll
have to manually bind and log/print for each event handler in a raw wxPython
app.

For most applications this won't be a problem because they don't handle
mouse move (wxMouseEvent) events or the file dialog isn't over an area of
the application window where the extra events will matter. However, if you
have a drawing application then the extra events are likely to be an issue
any time the user double-clicks to open a file rather than single clicking
the filename and then choosing the Open button.

So, the question is one whether this truly is a bug (it sure seems like it
is) and if so, whether there is a fix? If it isn't considered a bug, then
what is the best way to guard against the extra events or somehow safely
dispose of them, preferably when the dialog is dismissed?

The only thing I've come up with so far is to set a flag before the file
dialog is displayed and then reset the flag on idle. In the mouse down and
mouse drag handlers, if the flag is true they simply exit. This seems to
work, but falls into the "yuck" category of event handling workarounds. It
is quite possible that extra mouse events occur with other system dialogs or
user-defined dialogs too, so the workaround code might be required in a lot
of places, thus entering the realm of "extremely yucky".

It is not possible to simply set a flag on mouse down because if the mouse
down starts outside of the window where you are tracking the events, then as
the mouse enters the window, you will get a mouse enter and then mouse drag
events, but never see a mouse down. For a related reason, you may never get
a mouse up event if the mouse goes outside of the window (mouse leave)
before the user lets up on the mouse. LeftIsDown() is true for the mouse
enter event fired after the open dialog, so that isn't any help either.

ka

2

Kevin Altis wrote:

I remember bringing this up a long time ago, but I can't find a solution in
any of my code examples, so here goes again.

The problem is that, at least on Windows, if you double-click on a filename
in an open file dialog, then the file dialog closes, but extra mouse events
are sent to the window underneath the dialog where you double-clicked.
Specifically the app gets a single wxEVT_ENTER_WINDOW event, followed by a
number of wxEVT_MOTION events where LeftIsDown is true (aka a drag event).
This is very easy to see with the Message Watcher in PythonCard, but you'll
have to manually bind and log/print for each event handler in a raw wxPython
app

...

An intriguing question, Kevin - this may be another "yuck" solution, but how about extending the dialog class to put up a "safety net" panel behind it first, which will catch the wayward mouse events?

I wonder if we're once again 'stuck' due to the vagaries of the native dialogs...

Shi.

3

Kevin Altis wrote:

I remember bringing this up a long time ago, but I can't find a solution in
any of my code examples, so here goes again.

The problem is that, at least on Windows, if you double-click on a filename
in an open file dialog, then the file dialog closes, but extra mouse events
are sent to the window underneath the dialog where you double-clicked.
Specifically the app gets a single wxEVT_ENTER_WINDOW event, followed by a
number of wxEVT_MOTION events where LeftIsDown is true (aka a drag event).
This is very easy to see with the Message Watcher in PythonCard, but you'll
have to manually bind and log/print for each event handler in a raw wxPython
app.

For most applications this won't be a problem because they don't handle
mouse move (wxMouseEvent) events or the file dialog isn't over an area of
the application window where the extra events will matter. However, if you
have a drawing application then the extra events are likely to be an issue
any time the user double-clicks to open a file rather than single clicking
the filename and then choosing the Open button.

So, the question is one whether this truly is a bug (it sure seems like it
is)

Maybe.

and if so, whether there is a fix?

Probably not without changes to the native file dialog.

If it isn't considered a bug, then
what is the best way to guard against the extra events or somehow safely
dispose of them, preferably when the dialog is dismissed?

The only thing I've come up with so far is to set a flag before the file
dialog is displayed and then reset the flag on idle.

Or maybe something like this so you don't have to have a specific idle handler:

  self.DisableMyMouseEvents()
  if dlg.ShowModal() ...
    whatever
  wxCallAfter(self.EnableMyMouseEvents)

Or maybe this will work:

  wd = wxWindowDisabler()
  if dlg.ShowModal() ...
    whatever
  del wd

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

From: Robin Dunn

> The only thing I've come up with so far is to set a flag before the file
> dialog is displayed and then reset the flag on idle.

Or maybe something like this so you don't have to have a specific idle
handler:

  self.DisableMyMouseEvents()
  if dlg.ShowModal() ...
    whatever
  wxCallAfter(self.EnableMyMouseEvents)

Having an idle handler is simpler than trying to have methods that unbind
and then rebind the events, especially since you could have multiple event
bindings.

Or maybe this will work:

  wd = wxWindowDisabler()
  if dlg.ShowModal() ...
    whatever
  del wd

This doesn't appear to have any effect on the events.

I suppose this should be entered as a bug. I did a few more tests, and it
looks like the open/save file dialog is really the only system dialog where
a double-click can dismiss the dialog, I think everything else you need to
click OK, Cancel, etc. The wxSingleChoiceDialog can be dismissed with a
double-click in the list, but that isn't a system dialog is it? If not,
perhaps a workaround could be done for that dialog. The problem does appear
to be related to how the double click event is handled in a list, since
apparently there are leftover events afterwards.

ka

···

-----Original Message-----