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.
[ JDK VERSION : J2SE 1.4.2_02 ] Customizing a class creates an ArrayIndexOutOfBound Exception. To duplicate the error, follow the steps below - In the text editor, select any part within the class - from the popup menu, select Customize - In the Interface Box within the Customizer Dialog select Edit button - the above exception appears
The same happens for Methods. If there is no item in the listbox, the onlu Add button should be enabled.
Created attachment 13355 [details] The exception that should be thrown
The class customizer is not initialized properly. The edit button should be disabled.
Aha, I have found out the culprit. The properties infrastructure forces all components of the custom editor to set the enable property to true. Issue #38065 describes a workaround how to fix it so I try to follow it.
I can try to make it less aggressive, but AFAIK this code was written by David Strupl sometime around 3.3, and the only thing I did was copy it. I think I just fixed your bug - I've changed PropertyPanel to be less agressive, and not sync the embedded component's state unless it's been disabled on initialization. Leaving the "dontEnableMe" hack in, since this has been broken for a long time and at least that provides a workaround. But now, unless you disable your whole PropertyPanel, you'll never encounter the problem.
Tim, your fix resolved problem with the array editor. The modifier editor is still broken. I am investigating what's still wrong.
Huh, I got it. It relates to PropertyPanel.getPropertyEditor(). As you noted in javadoc it does not cache the supplied editor now. So the class customizer customizes the obtained editor instance which is thrown out a while later. If you do not consider it as a broken compatibility then it looks like a perfect candidate for the upgrade guide IMHO.
Yes, I'll document it in the upgrade guide. Along with that change, by default, Node now keeps a SoftReference to the property editor it returns from getPropertyEditor() (which means most uses of PropertyPanel aren't affected). Easiest way to solve it is just to do the same thing as in Node. Sorry for the difficulties.
I have a working patch. I had to migrate the model from ExPropertyModel to Node.Property (PropertySupport.Reflection). Otherwise I cannot cache the editor. FYI, it is not Node but Node.Property who caches the editor. Surprisingly PropertySupport.Reflection.getPropertyEditor() breakes that feature and with respect to propertyEditorClass value either caches the editor or not. It is quite inconsistent.
fixed /cvs/java/srcmodel/src/org/openide/src/nodes/ClassCustomizer.java,v1.4 /cvs/java/srcmodel/src/org/openide/src/nodes/ElementBeanModel.java,v1.5 /cvs/java/srcmodel/src/org/openide/src/nodes/FieldCustomizer.java,v1.3 /cvs/java/srcmodel/src/org/openide/src/nodes/MethodCustomizer.java,v1.6
*** Issue 39233 has been marked as a duplicate of this issue. ***
Well, migrating away from PropertyModel is a good thing - the propertypanel would simply generate an instance of PropertySupport.Reflection or a Node.Property wrapper anyway, so it's actually more efficient. Hopefully for Promo-D we can inject a little sanity in our APIs for this -deprecate propertymodel, and come up with a reasonable interface to implement over Node.Property and clear up some of the general junk. For this release, well, it ain't pretty (it never was) but it works...
Verified.
Reorganization of java component