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.
FileEditor(and subclass FilesOnlyEditory) property editor not updating property sheets. Bring up a property that uses the FilesOnlyEditor , for example the location property on a jar recipe, changes made in the property editor are not immediately shown in the property sheet. Clicking on the property in the property sheets seems to update it, but it is not persistant, dismissing the property sheet and then bringing it back loses the change. This problem appeared in 3.3 dev path.
Reassigned to me and core.
Decreased priority to P3 and reassigned to David. He'll explain solving of the issue.
Hello. I suggest to solve the problem by using new FileEditor from core. The FileEditor in openide has been deprecated in favor of the core one. The usage is even simpler than with the openide one. If you want to show directories only you just create the java.io.File property and pass custom parameter named files with value false. Please see explorer docs for details how to pass custom property for the editor. You can pass it either from beaninfo or from Node.Property. http://www.netbeans.org/download/apis/org/openide/explorer/doc-files/api.html#custom_property_editors I am reassigning the bug back to you since you know where the property is declared. I admit that you might see this as a regression but please note that i have already fixed this one in the new implemention in core. If you disagree please reassign back (and point me to the file where the property is declared). Thanks for your help.
Hi David, I changed the implementation to call the new core FileEditor as you suggested. (with property values : "files" = true, "directories"= false for files only mode) However, I am still seeing a similar inconsistancy. The Property sheet still shows the old text (even after clicking in it), but clicking the "..." will show the updated value in the property editor dialog. You mentioned that you fixed a bug in this area, has it been integrated yet? You can check the source at jarpackager/src/org/netbeans/modules/jarpackager/JarChildren.java
Hello again. I hope you wont mind if I pass it back to you. You should do something like firePropertyChange(JarDataObject.LOCATION_PROP,null,null); around line 200 in JarChildren. Could you please check whether this helps to solve the problem or whether the problem still persists? The change to use the core editor seems ok to me - if you have any problems with it please don't hesitate to file them for me to fix.
Hi David, I tried your firePropertyChange suggestion, but it did not seem to help(I did not see that it the sample code either). I did some experimenting and have narrowed it down a lot. The property editor does work in a lot of cases, browsing around in the filelist panel then hitting OK, changing the file name in the file name field - hitting Enter then hitting OK. However, if you make changes in the file name field and hit OK without hitting enter first, the changes are lost, this happened to be the scenario I was testing with. From some println's, it appears that the SetValue in the property in not even being called in that case. So I assume that the FileEditor property editor is not registering the fact that the file name field has been edited unless the enter key is pressed. I'm guessing that the FileEditor needs to check explicitly if the file name has been modified when the OK button is pressed.
This is difficult with JFileChooser -- it doesn't give you a way to access the text field directly. If you look at jarpackager/wizard/LocationWizrdPanel, you'll see the ugly hack the jarpackager used to use: locate the OK button by sarchng through the swing component hierarchy, and click this OK button when the user chooses the visible OK. I'm not sure even this is possible after setControlButtonsAreShown(false) is called.
Reassigned from properties module (properties module deals with Resource Bundle's!).
This looks rather complicated as pointed out by Mike. I am postponing the fix (if any) to next version. I really don't know what should be done about it.
Hello, After 3.3.1 release I am reevaluating this issue. And I came to this: the problem is that JFileChooser implementation does not notify us when the text is entered in its textfield unless you hit Enter. We have following options: 1. try to hack around this problem by digging into JFileChooser implementation 2. leave it as it is and wait for the JDK team to improve JFileChooser (it might be good idea to enter an issue for the JDK team) 3. not to use JFileChooser I am choosing the second because a. 1. is very risky and would require checks and changes with every future JDK version b. we don't have an alternative for JFileChooser I am marking this as wontfix. If you disagree please reopen and suggest what should we do.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.