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.
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.
Passing for evaluation to propertysheet subcomponent.
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 ***
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.
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.
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.
"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(...).
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).
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.
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.
Good point, I will add some notes to various places in Javadoc to try to remind people of the importance of correct property names.