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.
This property editor has a number of problems: - It is a JPanel that implements PropertyEditor. This means we're running a component constructor unnecessarily every time we want to paint its value in the property sheet, AND it can easily deadlock if constructed on a non-AWT thread - It overrides JComponent.add/removePropertyChangeListener, but not firePropertyChange. GTK/SynthLookAndFeel adds property change listeners to all components from within the superclass constructor (via ComponentUI.installUI(), called from updateUI()), which causes an NPE for this (and any other property editors like it). If the component is shown, it will probably not appear correctly on GTK because GTK/Synth L&F will never be notified of property changes (it looks for "ancestor"). I've fixed the NPE (deleting the add/ removePropertyChangeListener overrides) on the branch where I'm developing GTK support, to at least get it not throwing exceptions all over the place; no idea if it still works correctly as a result. Please fix or delete this class - it'll be one less deprecation message :-)
Reassigning to jpokorsky for evaluation.
Honzo, please set terget milestone, thanks.
Note all you urgently need to do is delete the add/remove property change listener methods - not much to do here.
I don't know if this issue is already fixed, or invalid, or I don't understand it at all, but ModiferEditor does not have add/remove PropertyChangeListener.
Okay, I was looking at the trunk's ModifiersEditor - I believe they are copies of each other. If this is already fixed on the java module's copy, forget it. The problem in the trunk was that ModifiersEditor is a JComponent subclass, so our implementation of add/ removePropertyChangeListener hides JComponent.add/removePropertyChangeListener. In GTK L&F, addPropertyChangeListener will be called from the superclass constructor (via updateUI()), before the PropertySupport is assigned in ModifiersEditor.<init> and throw an NPE. Implementing PropertyEditor directly on a Component subclass is a bad idea because the property editor may be created very frequently, and not in the AWT thread. But the immediate problem is the NPE on GTK L&F. Again, if your copy of ModifiersEditor doesn't do this, no worries.
Yes, they are slightly modified copies. ModifiersEditor does subclass JPanel but it implements ExPropertyEditor not PropertyEditor. JComponent.add/removePropertyChangeListener are overridden in ModifierPanel. I will have a look at it. I would like to remove all this ui stuff in some future release since the editor is the right place where to edit source files IMHO.
fixed in /cvs/java/srcmodel/src/org/openide/explorer/propertysheet/editors/ModifierPanel.java new revision: 1.7; previous revision: 1.6 /cvs/java/src/org/netbeans/modules/java/ui/nodes/editors/ModifierPanel.java new revision: 1.3; previous revision: 1.2