Name: krT82822 Date: 02/07/2000


original synopsis: "FileChooser: Directory traversal/Mouse event problem"

2/7/2000 eval1127@eng -- reproducible on NT 4 SP 6a. Couldn't find a duplicate for this particular problem, so am filing a new bug.

java version "1.3.0rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc1-T)
Java HotSpot(TM) Client VM (build 1.3.0rc1-S, mixed mode)


There is a serious issue concerning JFileChooser and mouse events
that makes the file chooser component very hard to use - at least
for me, but there are probably other users that have the same
problem.

I'm sure that you will agree that it is a rather common scenario
to open a JFileChooser dialog and use the mouse to click through
the directories in its file list view. For example, double-click
on folder X, contents of folder X are shown, then double-click
on sub-folder Y, contents of sub-folder Y are shown, etc., until
you've reached your destination folder.

Many (most?) users are able to perform this kind of directory
traversal quite fast (which is a good thing because locating a
file is an operation that is needed very often). However, this
means that the time between two double-clicks might be quite
short which will lead to the following problem:

Steps to reproduce:
- open a JFileChooser
- double-click on a folder
- (the file list view is updated to show the contents of that folder)
- double-click on a sub-folder that appears at the same position
  in the list as its parent folder before (e.g. first index)
- if the mouse position of the second double-click is similar
  to the position of the first double-click, and there was only
  a short time between both double-clicks, *nothing happens*
  -> the sub-folder will NOT be opened.

This is VERY annoying.

My guess would be that the "mouse click count" is what causes
the problem. Instead of recognizing the second double-click
as an entirely new double-click (click count=2), the AWT/Swing
mouse event handling system probably thinks that it's still the
first click (with a count of 4).

This kind of behaviour is not wrong in general; however, it is
wrong in this special case. By changing the directory and thus
the contents of the file list view, the logical state of the
component has changed. What needs to happen at this point is
that any internal mouse click counts are somehow reset to 0
because clicking on the "new" list contents is, logically, a
completely new, separate event - even if it occurs very soon
after the old event (the first double click).

The only workarounds a user can currently employ are:
a) wait some time between two double-clicks
b) try to click on different locations of the list entry/entries
Both are unacceptable.

As a result of all this, effective directory traversal is not
possible using JFileChooser. There are a gazillion other
bugs that prevent professional use of JFileChooser but if you
agree that the problem described above exists, please consider
fixing this one with a higher priority.

I should add that I'm using the default Windows double-click
speed setting and that I have no problems whatsoever with
the standard Windows file dialog in this respect.

Best regards,
Henrik
(Review ID: 100891)
======================================================================

Name: krT82822 Date: 02/26/2000


java version "1.2.2"
Classic VM (build JDK-1.2.2-001, native threads, symcjit)

1. Start any Swing application which uses JFileChooser
2. Select File->Open to pop up the chooser
3. Try drilling down into subdirectories using a Wacom PenPartner graphics
tablet.... IMPOSSIBLE. The JList inside the chooser doesn't react to the pen's
clicks.

ALL OTHER WINDOWS AND JAVA PROGRAMS REACT TO THE PEN AS IF IT WAS A MOUSE. THIS
PROBLEM **ONLY** OCCURS WITHIN JFileChooser !!!!!!
(Review ID: 101779)
======================================================================