Bug 15610 - File property editor not updating value from the JFileChooser's text field
File property editor not updating value from the JFileChooser's text field
Status: CLOSED WONTFIX
Product: platform
Classification: Unclassified
Component: Property Editors
3.x
PC Windows 3.1/NT
: P3 (vote)
: 3.x
Assigned To: David Strupl
issues@platform
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-09-18 21:46 UTC by Brad Ashby
Modified: 2008-12-22 23:40 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brad Ashby 2001-09-18 21:46:24 UTC
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.
Comment 1 Peter Zavadsky 2001-09-19 07:25:39 UTC
Reassigned to me and core.
Comment 2 Peter Zavadsky 2001-09-19 08:55:03 UTC
Decreased priority to P3 and reassigned to David. He'll explain
solving of the issue.
Comment 3 David Strupl 2001-09-21 16:37:34 UTC
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.
Comment 4 Brad Ashby 2001-09-25 22:42:02 UTC
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
Comment 5 David Strupl 2001-09-26 13:23:30 UTC
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.
Comment 6 Brad Ashby 2001-09-26 19:33:09 UTC
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.
Comment 7 Mike Schilling 2001-09-26 21:16:10 UTC
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.
Comment 8 Peter Zavadsky 2001-09-28 09:58:04 UTC
Reassigned from properties module (properties module deals with
Resource Bundle's!).
Comment 9 David Strupl 2001-10-17 15:23:32 UTC
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.
Comment 10 David Strupl 2002-02-01 12:08:32 UTC
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.
Comment 11 Quality Engineering 2003-07-01 15:52:48 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified.

Comment 12 Quality Engineering 2003-07-01 16:20:56 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo