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.
The custom property editor for File properties - file chooser dialog - does not support for selecting non-existent filename. The file selected in the editor is stored to the property only when an existing file is selected, not when a new filename is typed in. Steps to reproduce: create a jarRecipe, select its Jar Target property, click (...) to bring up the file chooser, select some other directory, where the target jar file should be put, click o.k. => the property value was not updated
Property editors?
I just tested this with a very simple bean with one property of type File. Create such a bean, and add logging when the File property is set. Run Customize Bean. Use the custom editor to enter a non-existent file and click OK. The file is updated correctly. Then I tested this with the Location property of a new Jar Recipe. It also works correctly. I don't know what the Jar Target property is, the jar recipe I created did not have a property with that name. Anyway, the custom editor for File supports nonexistent files with no problem. Maybe you are passing a file filter as a hint or something, which blocks use of nonexistent filenames?
verified
Just got another bug report for this and reproduced it easilly. I don't know what is verified but it does not work and jarpackager is not using in any special way and , as also mentioned in the duplicate, it appears for other properties not in jarpackager. Reopening.
*** Issue 41080 has been marked as a duplicate of this issue. ***
not a showstopper for 3.6 -> promo-d
Given that jar packager is dead, what is the priority of this? I could reasonably see this as an enhancement that a property could provide a hint that the chooser should allow non- existent files. Status?
Given that jar-packager is dead, I don't mind if you can close it as wontfix.
Ondrej, I'd rather make sure there's no bug here. Can you provide *exact* steps to reproduce when customizing a simple bean, ala. public class Foo { private File file = new File("/tmp/foo"); public File getFile() { return file; } public void setFile (File f) { this.file = f; } } As I mentioned, I had no problem making this work whatsoever - so I will assume that something was wrong in JarPackager; also I still don't know what the jar target property is.
1. create new java class 2. paste the code for Foo, add import for java.io.File , compile 3. Right-click - "Customize bean" 4. Click ... to bring up the property editor Bug1: 5a. click "<--" (for parent folder) , ok ---> ! no change saved Bug2: 5b. navigate to some folder 6b. skip to "File Name" text field and fill in "foo.jar", OK --> ! the new value is just the folder, the filename "foo.jar" was stripped off In jar-pacakger, the "Location" property (that's my "jar target" as you have correctly guessed, sorry for the confusion, it's called "jar target" in the code) is just a plain ReadWrite property of type "java.io.File". It has the following two properties set (see jarpackager/src/org/netbeans/modules/jarpackager/JarDataObject.java, line 708): p.setValue("files", Boolean.TRUE); p.setValue("directories", Boolean.FALSE); The property editor behaves somewhat differently in that the name of the jar file remains filled in the "File Name" text field while browsing the filesystem by dbl-clicking folders. In the testing bean, the filename is overwritten when a folder is clicked with the folder name. In jar-packager, when you click OK , nothing is saved unless a file was selected by dbl-click. If it was typed by hand, nothing is saved. In the testing bean, a filename typed by hand is stripped off. Anyway, you can just stop by and I'll show you.
Passing property editor issues to new owner, Jirka
There is the workaround and almost all clients of this chooser are dead, the issue's relevance is marked lower => I decrease the priority to P4.
I guess this won't be fixed for NB4.0 , please evaluate again.
Per Ondrej's agreement it's closed as WONTFIX.