JDK-4528663 : JFileChooser doesn't return what is typed in the file name text field.
  • Type: Bug
  • Status: Closed
  • Resolution: Not an Issue
  • Component: client-libs
  • Sub-Component: javax.swing
  • Priority: P3
  • Affected Version: 1.4.0,1.4.1
  • OS: generic,solaris_9
  • CPU: generic,sparc
  • Submit Date: 2001-11-17
  • Updated Date: 2004-11-12
  • Resolved Date: 2003-02-04
Related Reports
Relates :  
Relates :  
Relates :  
Description
The "getSelectedFile()" method is supposed to return the selected file. A valid method to select a file is for the user to type the filename into the UI. However, this method returns only the file that the user had selected from the list, or if they pushed Enter after typing in the file name text field.

This is important for when the JFileChooser does not have the associated Open/Save buttons associated with it that seem to trigger reading and storing the text field contents into SelectedFile. If user types into the text field without pressing return or the Open/Save button, it is impossible to retrieve that string. 

For an example, see NetBeans (using v 3.3, but probably exists in earlier and later versions), File | Mount Filesystem wizard, "Select Directory" panel. 

Request a way to retrieve the contents of the text field - whether it be to have getSelectedFile() return this, or some other method. 

Name: rmT116609			Date: 12/12/2002


 DESCRIPTION OF THE PROBLEM :
If the user types a file name after having selected a file, the file returned by getSelectedFile is null.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Compile and run the program below

2. Select a file
3. Change its name in the "File name" text box
4. Press Open.

EXPECTED VERSUS ACTUAL BEHAVIOR :
expected: the file name typed should be printed
actual: null is printed

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
public class Teste {
    public static void main(String[] args) {
        JFileChooser fc = new JFileChooser();
        fc.setMultiSelectionEnabled(true);
        if (fc.showDialog(null, null) != JFileChooser.APPROVE_OPTION) return;
        System.out.println(fc.getSelectedFile());
    }
}

---------- END SOURCE ----------
(Review ID: 165557)
======================================================================

Comments
EVALUATION See Workaround section for a simple way to avoid this problem. This bug needs to be fixed in a future release. ###@###.### 2001-11-19 Name: keR10081 Date: 01/31/2003 The method getSelectedFile() should return File, not just a string from the textfield that user entered. However, in case of a single selection JFileChooser the dirty trick works - we can get incorrect file name. I doubt that we should allow to return incorrect file name. Note, though, that if we first select file via mouse click and then change the name in the textfield to a CORRECT (existing) file name, we get it via getSelectedFile() call. If we do not have approve button, we can call approveSelection(). Considering the need of retrieving textfield's value. ###@###.### ====================================================================== Name: keR10081 Date: 02/04/2003 Furthermore, we have a BasicFileChooserUI getFileName() method that does just that. So, if we change the last line to System.out.println(((javax.swing.plaf.basic.BasicFileChooserUI)fc.getUI()).getFileName()); everything works. Closing this out. ###@###.### ====================================================================== I don't agree with having this workaround. It seems on the burden of the developer to check if the name of the file is valid. For instance, if the developer wants to present a JFileChooser, and can only test for the validity of the file *after* the JFileChooser goes away, then it is the burden for the developer to relaunch the JFileChooser at the last directory for the user to choose again. A preferred behavior would be for the JFileChooser dialog to remain up after the user chooses the Open/Select button, and the user could be presented an error dialog on top of the JFileChooser saying that this file doesn't exist. After dismissing that, the JFileChooser will still be up so the user can choose or type in a new filename. So, what i think i'm asking for is an API change that would make it more convenient for the developer to easily use JFileChooser to create a user friendly interface. As i see it now, with your suggestion of developer using the getFileName() to check on the case if the user had typed something in, the developer will *always* have to call that first in order since getSelectedFile() would only return what is selected. Why make the developer do these two steps? This is how it seems to work with other OS filechoosers. Thanks, I'd appreciate a response. ###@###.### 2003-02-04 ====================================================================== The workaround is intended for applications that *do not* use the standard OK/Cancel buttons in JFileChooser, maybe because they embed the filechooser in a "wizard" or similar. For a normal JFileChooser dialog, you definitely do not need to wait until the dialog disappears before you can validate the file name. The following example will hopefully be added to the next version of the Swing Tutorial. JFileChooser fc = new JFileChooser() { public void approveSelection() { File f = getSelectedFile(); if (f.exists()) { super.approveSelection(); } else { JOptionDialog.showMessageDialog(this, "The file "+f+" does not exist"); } } }; ###@###.### 2003-02-04
2003-02-04

WORK AROUND The following example makes an explicit call to the UI class to approve the typed in value. The file can then be retrieved as usual with getSelectedFile(). Please note that this workaround is specific to 1.4.0 only. import javax.swing.plaf.basic.BasicFileChooserUI; [...] if (fc.getUI() instanceof BasicFileChooserUI) { BasicFileChooserUI ui = (BasicFileChooserUI)fc.getUI(); ui.getApproveSelectionAction().actionPerformed(null); } ###@###.### 2001-11-19 ---------------------------------------------------- The above workaround should work for 1.4.* and 1.5.0 as well. ###@###.### 2004-11-12 22:03:41 GMT
2001-11-19