I am developing a custom datepicker component. If using the component in a normal swing application I am getting no problem at all. The problems arises when trying to attach beanbindings to a property in a form bound to the date value of the control.
So the sistuation is inside a JPanel form where I have a property, which is not updated properly when the date value changes in the datepicker component, although the date holder member in the datepicker holds the value as expected, so the point is that the bindings do not work properly with my component.
I am aware this is very basic issue about beanbinding handling, so from my general knowledge I pressumed I had to introduce a ProperyChangeSupport in the datepicker in order for the correspondent bindinglistener to process the change event in the date holder member in the control.
And there I get the strangest thing I have ever seen.... the propertyChangeSupport instance holds a null value, although it should have been created at declaration time such as :
PropertyChangeSupport propertyChangeSupport = new PropertyChangeSupport(this);
As you know the instance is used to fire a propertychange event when a bound property is changed, and I presume that is why I am not getting my binding working properly. Since the datepicker inherits from JTextField, I ensured "super();" was called at every constructor, but still no luck! How can it be that it is created at declaration and inmediately be destroyed.
I hope I made myself clear enough for you to understand my problem. This seems to be a silly problem but so far haven't found a solution, and can't find any valid workarounds.
If you're sure that you initialized the instance field propertyChangeSupport then the only simple explanation is that you have a local variable with the same name that is null.
By the way, I would suggest you use SwingPropertyChangeSupport for the reason noted in its documentation: that it can be made to fire its events on the EDT.
There are no new questions, but there may be new answers.
posted 9 years ago
Hi darryl thanks for your quick answer.
The member declaration includes instance creation, however I think I might know what's going on.
Since this is an extension of the Jtextfield, I presume that upon initialization of the super class, and arrangement of the Panel, the method addPropertyChangeListener() of the super class tries to execute (which indeed does, when trying to install a DefaultCaret on the control), but when Netbeans Wizard creates the property, it overrides the addPropertyChangeSupport() method, but since the code execution is still on the super class, the instance in the datepicker control has not yet been initialized. That would be an explanation I guess. So what I did is to make use of the super instance propertychangesupport, and although haven't got the whole thing to work, exceptions are not there anymore.
Now I believe I must additionally figure out a way to promptly bind my custom property to the beanbinding, but I think that's another issue more related to beansbinding which I am missing. I you're interested I wll keep you posted. Do you know any thorough source where I could find further hints?
A sonic boom would certainly ruin a giant souffle. But this tiny ad would protect it: