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.
I am creating a custom bean that depends on a custom property editor. My custom editor extends PropertyEditorSupport and implements XMLPropertyEditor. The model is an Object for which I've implemented equals, toString, and fromString. - Java initialization string works (can be verified in the Java code) - XML serialization works (can be verified in the form) However: - The component is not responding to the changes, that is the internal state is not being updated, it appears that setValue is not being called - The string representation appears correct in the property pane but if changes are made in the cell (not the editor, but the cell in the property pane using the text format) an error is thrown.
Created attachment 123029 [details] file for case
Created attachment 123030 [details] file for case
Created attachment 123031 [details] file for case
Created attachment 123032 [details] file for case
Not sure what setValue call you mean in the first problem. Do you mean that RedBlackTextField.setRedBlackData does not get called with the new instance from the custom property editor panel? BTW I see you are able to use XMLPropertyEditor, so you could perhaps also try to use ExPropertyEditor: http://bits.netbeans.org/dev/javadoc/org-openide-explorer/org/openide/explorer/propertysheet/ExPropertyEditor.html and PropertyEnv: http://bits.netbeans.org/dev/javadoc/org-openide-explorer/org/openide/explorer/propertysheet/PropertyEnv.html This should allow you to get informed when OK button is pressed and set the value in the property editor only at this moment. You can also do some validation at this point. But otherwise, the property editor (RedBlackEdito) looks correct to me at the first sight. So there might be a bug on NetBeans side, we need to try out and debug. There's some chance it's not exposed when using the ExPropertyEditor. As for the second problem, you don't mention what error is thrown, but I'd say your property editor is missing getAsText and setAsText methods to allow editing of the value as a String.
Hi, thank you for getting back so soon. On the first problem, the issue I have is that the paintComponent method in RedBlackTextField is showing blank info for red and black, even after you set RedBlackData in the RedBlackEditor. I would expect that the internal state of RedBlackTextField would be updated. On the second problem, I have added the following code in the editor: /** * {@inheritDoc} */ @Override public String getAsText() { try { return getValue().toString(); } catch (Throwable IDontCare) { return ""; } } /** * {@inheritDoc} */ @Override public void setAsText(String text) throws IllegalArgumentException { try { setValue(RecordData.fromString(text)); } catch (Throwable IDontCare) { throw new IllegalArgumentException(IDontCare.getMessage()); } } and now it works! Thanks for the hint - I look forward to your findings on the component state.
OK, I see what the first problem is. The property editor actually works well. The problem is with the RedBlackData property value. The GUI builder gets an instance from the property editor, but needs to create a copy of it to set it to the design view - which it can't in this case. There are basically two equal instances for each component (RedBlackTextField in your case): one is used as the reference instance in the model (for property sheet, generated code, persistence) and a separate instance is used for the design view. If you invoke a preview of the form, yet another instance gets created. This means that also property values set by the user need to be copied among the components. The only way GUI builder can make a copy of a custom data type is serialization. So it should work for you if you make RedBlackData Serializable or Externalizable. If the property value type is simple, it should be easy and work just well. It could also be used instead of the XMLPropertyEditor implementation (which is OTOH more suitable for the "long term" persistence in the form file, but you may get along without it if you can keep your data serialization stable). We should perhaps look into the possibility to share the same instance of the property value for design view as a fallback if it can't be cloned - instead of not setting it at all as it seems happening now.
I've changed how the property values cloned for the view are handled if can't be cloned: same instance is used instead of not setting it to the view component. http://hg.netbeans.org/jet-main/rev/95617f8a01e7 There's a small risk in this change. The previous behavior ensured that same property value instance was never set to multiple components. If could not be copied, it was not set. This was safe. Now some failures could happen, theoretically, if some special properties can't share the value instance between more components and can't have the values serialized. But I think it's rather hypothetical that someone would have a component and rely on that it's property is not set in the design view. Such a component is not suitable for use in GUI builder anyway. To the reporter: The fix will be available in next NetBeans version. For now you need to make the RedBlackData class Serializable.
Integrated into 'main-golden', will be available in build *201208211308* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/95617f8a01e7 User: Tomas Pavek <tpavek@netbeans.org> Log: #216775: if can't clone property value, use the same instance instead of ignoring it
*** Bug 220504 has been marked as a duplicate of this bug. ***