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.
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
Hello again. I hope you wont mind if I pass it back to you.
You should do something like
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
I'm not sure even this is possible after setControlButtonsAreShown(false) is called.
Reassigned from properties module (properties module deals with
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.
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
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.