This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
dev build 200211290100 Previously if I tried mounting a directory and entered "c:\ <enter>" the GUI would display the contents of the root directory. Now it just sits there. Expected behavior: If I enter "c:\" and press ENTER, the file chooser should display the contents of that directory. If I press "FINISH" it should mount "c:\" If, however, I selected a directory inside "c:\" before selecting "FINISH" it should mount *that* directory instead I think this behavior will satisfy both keyboard and mouse users.
TemplateWizard issue
*** Issue 25584 has been marked as a duplicate of this issue. ***
Open File System Wizard. Select some type of file system. Type path to filesystem in File edit field. Finish button is not enabled, etc. It is necessary to add listener to edit field.
*** Issue 29336 has been marked as a duplicate of this issue. ***
Version changed: 4.0 dev -> S1S 4.2
*** Issue 30111 has been marked as a duplicate of this issue. ***
*** Issue 30155 has been marked as a duplicate of this issue. ***
priority incresed because there is many the same reports
There is a problem with keyboard usability of FileArrayEditor (it used in Mount Wizard for select the root of local filesystem or jar filesystem). The editor doesn't fire enough changes of selectedFile property and cannot select a folder/file direct by keyboard. Note: the defect persists from 3.3.2 and 3.4 too, I vote for decrease a priority back.
Just started digging into this - there's a bunch of weirdness going on here. On Solaris, type "/" and the directory immediately switches to the fs root, *and* the JTextArea loses focus. For some entries, the selected directory randomly switches back to my home directory, or displays one directory name in the text area, and a different on in the table. My initial impression is that the core problems are in JFileChooser; also, fixes to this issue could cause strange problems on different look and feels that implement the dialog differently.
I think the initial problem is that in Metal L&F, the directory selection component gets the initial focus. It does respond, for example, to the / character, but it does not fire changes. I've written a variation which goes so far as to iterate the component tree of the JFileChooser and find the JTextArea of the file chooser, but so far none of my efforts to force focus to it are working.
More info: Apparently there is a hack in the Wizard infrastructure to force focus to the first component in the main panel (to work around focus being set to the container or someplace else on JDK 1.3). This is what is forcing focus to the wrong place, causing keyboard navigation not to work right. In a stand-alone JFileChooser dialog, focus is correctly set to the JTextArea inside it. Jano, David Strupl tells me probably you did the work on the original focus hack. I'll dig around for it, but it would save me much time if you could let me know what and where this it is.
This issue is caused by the fix for issue 17794. If I comment out line 214 in NbPresenter.java, "requestFocusForJdk14(comp);" it works correctly on 1.4.1. I also cannot reproduce issue 17794 with this line commented out - all wizards and dialogs work as intended with focus set correctly. I have disabled the hack for JDK 1.4.1 and above, and it works correctly. I'm marking this as fixed, 1.4.1 specific. If someone is not dissatisfied with this, please reopen - I have a few other P2 bugs to attend to, so at least for the time being, it working on 1.4.1 may need to suffice.
It doesn't work. Example on my linux: "/" <enter> show "/" dir "/mydir" <enter> doesn't show dir "/mydir" etc.
Petr, could you tell me what component *does* get focus when you initially get to the file editor page of the wizard? It works correctly on 1.4.1/Solaris.
I've added some additional work in the AbstractAction created by FileEditor.hackJFileChooser(), which should take care of this problem. Note that it does not eliminate *all* keyboard issues - there is some weirdness in the way JFileChooser does things, at least for the case of Metal L&F. In particular, there are some cases where a legitimate file name is present, but the file chooser returns the selected file as null, and offers no way to find out what the user actually typed. To solve it properly, without depending on impl details of its UI really requires writing our own UI for it or firing bugs/enh requests at the JDK team.
The bug parade search does not show any hits for JFileChooser. JFileChooser: If a file name is typed whose parent exists but the file itself does not yet exist then nothing is returned. This is easy to reproduce and easy to understand. In comparison try any InstallShield installation. It will let you do this and it asks you whether the new directory you typed should be created. I am writing an installer in Java and found no way to do this. http://developer.java.sun.com/developer/bugParade/bugs/4031440.html tells me that I cannot use the AWT dialog because of broken file type filtering. So if you have good connections to the swing team maybe you can address this more generally. I am a bit hesitating still to raise a bug at this stage.
I know there is at least a Sun internal issue on keyboard navigation of JFileChooser. The main problem is really that the L&F encapsulates the components and such a little too well - you can't even usefully subclass the Metal UI, because all of the components used are private, so there's no contract that they won't change. If you're willing to live dangerously, you could play with the patch I posted on nbdev the other day - it allows completions & such, and makes it more keyboard friendly (but it's a major hack). We are trying to get the situation with JFileChooser improved.
verified in [nb_dev](20030904)