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 had an issue on nbusers where the person was trying to set the page property (setPage(java.net.URL)) of the JEditorPane class. He was using: getClass().getResource("/some/package/of/his/somefile.html") using custom code to set the value. The form module is trying to actively parse and set this value, I assume to make the UI display at design time as it will at runtime. The problem is the URL resolves to null until the project is run. Run single will not work, so it seems the JAR or runtime classes have to have been built before run single will work and resolve the URL. It seems like a class loader issue, and I'm not sure if it is in the project API support or in form. I figured I better file it while I remembered it so that it can be tracked down at some point. I created a couple new projects using 6.0 release all with the same result. Anyways, it seems any resources should be available at design time or if they can't be then it should not try to actively display a property or give the user the ability to tell the UI designer the property won't resolve until runtime. Maybe use some check box and a message to apply this.
More info I forgot. The message in the IDE is the property could not be saved. The error message thrown by JEditorPane is the URL is invalid. setPage throws an IOException. getResource is returning null though at runtime it will return the correct path.
Pretty weird bug. Looks like caused by the fix of issue 87647 - but the culprit is JEditorPane. It does not allow null to be set to its 'page' property - even though null is actually the default value of the property. 87647 tries to set the default value to the target component property if the set value is user code - which fails. Just try to set this property to some user code - you get an error. Forms created earlier will open with error. This could be fixed by checking if the target value is not already a default one and don't set it unnecessarily. Same hack should probably be applied when reseting the property value to default. And we should definitely file a bug on JSplitPane.
...err - file a bug on JEditorPane, not JSplitPane (this time)...
This issue is clearly a bug in JEditorPane. I don't think that it is appropriate to change general behaviour of RAD/FormProperty bacause of this issue only. I believe that it is better to add a workaround specific to this issue. It is also safer. The suggested approach would require comparing of current value with the new value. It may seem simple at first sight, but plain equals() may not work well - that's why there are methods like FormProperty.equals() or Utilities.compareObjectsImpl(). This approach is suspicious in that it solves broken contract in one area (setter doesn't accept value returned by getter) by blind belief that another contract (equals() method on property values) will be satisfied. Workaround added, modified file: /cvs/form/src/org/netbeans/modules/form/RADProperty.java new revision: 1.37; previous revision: 1.36
It seems a general fix is needed though. Say someone has another 3rd party library they want to use. Say it also has some property where the default value can not be reapplied, but the user code that will be used will set the value successfully. In that case the user just sees it as the value they are trying to set in the form editor doesn't work. I don't know. In either case it could be considered a bug in the 3rd party library, but if we could work around if the user code which will set the property works correctly versus setting it back to the default value then it seems like it would allow the IDE to be used for what it does best without the person having to wait on a fix in the 3rd party API, and even then it can be argued it isn't a bug in the 3rd party library as the JavaBeans specification doesn't say setProperty(getProperty()) for a newly created instance (thus all defaults) should complete successfully for it to be a valid JavaBean. They are after all trying to set a property to a value besides the default value in these cases, and it is a value which will work correctly with the library, so it seems like the form editor should just not set the value to anything at all if it is setting a property to its default value. This is after all the philosophy of the XMLDecoder and XMLEncoder for long term storage of beans. It never stores beans set to the default value and thus never calls the setter to set a property to its default value when de-serializing a long term serialized object.
I agree that there are hypothetical cases where the approach suggested by Tomas would improve the current behaviour. On the other hand, as I noted before, there are (also hypothetical) cases where it would make the behaviour worse. There are a lot of real (e.g. encountered and reportered by our users) problems in the current GUI builder. Hence, it doesn't have a sense to waste our time on hypothetical problems. I was willing to include a workaround for JEditorPane because it is component that is widely used and there is probably no chance to have it fixed (at least not in the next 1-2 years IMHO). I would like to minimize introduction of workarounds that are not really necessary. The GUI builder already includes TONS of them and it is real pain to maintain them.