JDK-6260676 : FileDialog.setDirectory() does not work properly, XToolkit
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_sun
  • CPU: x86
  • Submitted: 2005-04-25
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b15Fixed
Related Reports
Relates :  
Description
FileDialog is set with a file name already through setFile() method call. I am opening the file dialog and navigating through the directories listed. I am selecting one of the files and without clicking 'OK', I am closing the dialog using 'close' button on the top-right corner of the dialog(GNOME) or using the 'close' option in the menu (CDE). I expect the selection to be cancelled and I expect getDirectory() and getFile() to return null values respectively. But FileDialog returns the currently highlighted dir for getDirectory() and the programmatically specified file name for getFile(). This is incorrect. Closing the dialog is currently treated equivalent to clicking OK. All the selections must be nullified when closing the dialog without pressing OK.

This is reproducible on XToolkit since Tiger. On Motif, getFile() behaves incorrectly but getDirectory() behaves properly. On Win32, getDir() as well as getFile() returns null when closing the dialog.

I have attached a sample test. Execute the sample test. Click one of the buttons shown on the frame. Navigate through some folder and click on a file name. Press the close button on the top-right corner or select the close option from the menu (which comes up by pressing ALT+SPACE). If you don't see 'null/null' message on the console, the bug is reproduced.
###@###.### 2005-04-25 13:36:35 GMT

Comments
SUGGESTED FIX #sccs diffs -C XFileDialogPeer.java ------- XFileDialogPeer.java ------- *** /tmp/sccs.V6aGMY Tue Jun 5 12:32:45 2007 --- XFileDialogPeer.java Tue Jun 5 12:05:06 2007 *************** *** 299,305 **** target.addWindowListener( new WindowAdapter(){ public void windowClosing(WindowEvent e){ ! handleQuitButton(); } } ); --- 299,305 ---- target.addWindowListener( new WindowAdapter(){ public void windowClosing(WindowEvent e){ ! handleCancel(); } } ); *************** *** 405,411 **** directoryList.clear(); fileList.clear(); target.setFile(null); ! target.setDirectory(savedDir); handleQuitButton(); } --- 405,411 ---- directoryList.clear(); fileList.clear(); target.setFile(null); ! target.setDirectory(null); handleQuitButton(); }
05-06-2007

EVALUATION Current implementation of the FileDialog class doesn't provide any explicit method to get the return value after the user closes the dialog. The only way to detect whether the user cancels the dialog or the user selects any file is to use the getFile() method. The getFile() method should return null value if the user cancels the dialog or non-null value if the user selects any file.
16-06-2005