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.

Bug 31431

Summary: Property windows of system option node do not reflect changes made in any of them
Product: platform Reporter: Martin Brehovsky <breh>
Component: ExplorerAssignee: _ tboudreau <tboudreau>
Status: CLOSED DUPLICATE    
Severity: blocker CC: dkonecny, jglick
Priority: P3    
Version: 3.x   
Hardware: PC   
OS: Windows ME/2000   
Issue Type: DEFECT Exception Reporter:

Description Martin Brehovsky 2003-02-25 11:27:53 UTC
When opening several property windows on a system
option node, any change of a property in any of
the windows does not apply the changes to the
other windows. 

This wrong behavior can be seen on several nodes
(e.g. XML Editor Settings, Editor Settings,
Annotation Types, JUnit, and more)in system
options. Other nodes seem to be working correctly.

As a owner of JUnit module I can see the described
problem in my module as well. JUnit settings are
just a class extending
org.openide.options.SystemOption class and body of
the setters use 'putProperty(propertyName, newVal,
true)' method, therefore my settings are
definitely firing the property changes, but these
are not reflected by the property windows.
Comment 1 David Konecny 2003-02-25 11:35:16 UTC
Passing for evaluation to propertysheet subcomponent.
Comment 2 _ tboudreau 2003-02-25 12:25:29 UTC
Looks like the same issue as 31413 - properties being added but this
not being reflected in the property sheet.  Probably it is not
listening or responding to its listener correctly.  I am 
investigating.

*** This issue has been marked as a duplicate of 31413 ***
Comment 3 _ tboudreau 2003-02-25 17:31:11 UTC
Check that your node is firing property changes where
propertyChangeEvent.getPropertyName().equals (theProperty.getName()) -
the property sheet code is working correctly - and ignoring property
changes for properties with names it does not know about.
Comment 4 Martin Brehovsky 2003-02-25 17:39:27 UTC
Yes, it does, because it's a SystemOption bean and all setters are use
'putProperty(MY_PROP_NAME, newVal, true)'.

Yesterday I created a patched version of SharedClassObject to see
whether the changes are really fired. They are.
Comment 5 _ tboudreau 2003-02-25 18:24:19 UTC
Perhaps there is a problem in SharedClassObject.  If you look at the
code for PropertySheetTab, you will notice it populates a cache of
PropertyModel objects, keyed by property.getName().  

If I add logging to PropertySheetTab and change a JUnit setting,
here is the output:

Cache contents: Property not in cache: body_content
Cache contents:
BodyContent,GenerateAbstractImpl,GenerateExceptionClasses,ClassTemplate,GenerateSuiteClasses,MembersPublic,IncludePackagePrivateClasses,BodyComments,FileSystem,CfgCreateEnabled,MembersProtected,JavaDoc,MembersPackage,SuiteTemplate,Property
not in cache: body_content

The problem is that BeanNode generates the property change
events, and it doesn't know anything about the names used for
putProperty.  You need to change your BeanInfo so the names match
the constants in your class.
Comment 6 Jesse Glick 2003-02-25 18:50:41 UTC
"You need to change your BeanInfo so the names match the constants in
your class." - vice-versa I would say; use constants in
firePropertyChange which match the natural JavaBeans property names,
e.g. PROP_FOO_BAR = "fooBar" for setFooBar(...).
Comment 7 Martin Brehovsky 2003-02-26 10:24:47 UTC
Ok, that's explains the thing. I changed the property names to match
the JavaBean property names and now the changes are propagated
correctly - I'm closing the issue. 

Just wondering is this fact mentioned in doc? I was reading it, but I
didn't saw anything like that (may be it is mentioned, but I just
didn't found it, or didn't pay any attention to that).
Comment 8 Jesse Glick 2003-02-26 17:49:19 UTC
Well I think JavaBeans spec and docs for PropertyChangeEvent are
pretty clear on what property names mean and how you can fire events
in them. NB doesn't really deviate from that spec AFAIK.
Comment 9 _ tboudreau 2003-02-26 18:14:26 UTC
Might not hurt to mention it in the docs for putProperty, even if
it's due to be deprecated, and maybe some commented node in 
relevant templates in APISupport - it seems the assumption that
using putProperty means that name will become the property's name
is the source of people's problems.
Comment 10 Jesse Glick 2003-02-26 18:36:03 UTC
Good point, I will add some notes to various places in Javadoc to try
to remind people of the importance of correct property names.