mouse double click problem

[Tis Veugen]

Hi,

The u/i of my Java application has the following problem.
Inside a panel a mouse double click causes a popup of another window. In
that window there is a JList with some items. One of these items must be
selected based on a previous selection. However, if the mouse is positioned
such that it covers the JList, then the item at the mouse pointer becomes
erroneously selected. Probably, due to the second click of the mouse. I
tried to consume() the current mouseEvent, but no success.
Is there a way to clear all pending mouseEvents?
Or does somebody know another solution?

Thanks,
Tis Veugen

 

[Andrew Thompson]

Tis Veugen wrote:
....

Or does somebody know another solution?

Not a solution, as such, but a strategy, is to prepare
an SSCCE That demonstrates the problem.
<http://www.physci.org/codes/sscce>

Andrew T.

 

[John Ersatznom]

Tis Veugen wrote:
...



Not a solution, as such, but a strategy, is to prepare
an SSCCE That demonstrates the problem.
<http://www.physci.org/codes/sscce>

This is a widespread Windoze problem rather than a Java problem. MSWin
generates a click event for the second of a double click, separately
from the double click, and apparently posts it somewhat after the double
click.

One place this causes headaches is on file upload websites with large
Flash ads covering half the page and a form that produces a file
selection dialog for the file to upload. When you pick a file and double
click it, the second click penetrates through, usually onto a Flash ad
that then does something annoying (e.g. navigating the browser off the
upload site and losing the upload while also, probably not
coincidentally, generating revenue for the upload site). This happens in
Firefox and other non-Java browsers.

Unfortunately, there's no "clean" way in Java or out of it to consume an
event that the OS hasn't even posted yet.

You could set a timer and create the popup with its controls initially
disabled, or the popup itself not visible, and then make it
visible/enabled when the timer expires after say 1/2 second. Then the
extra click will get eaten when it does get posted. The delay before the
new dialog works needs to be long enough to eat that click, but short
enough not to trip up users that become familiar enough with your UI to
expect it and immediately begin trying to enter data rather than
spending time determining what just happened. (New users will look at
the dialog and figure out what it's for; experienced users will
anticipate it and immediately begin putting in data they'd already
thought ahead on.)