Bug 294734 - [DataBinding] ControlObservableValue and TextEditableObservableValue should get notified by controls
Summary: [DataBinding] ControlObservableValue and TextEditableObservableValue should g...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-10 08:41 EST by Tillmann Seidel CLA
Modified: 2019-09-06 16:09 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tillmann Seidel CLA 2009-11-10 08:41:17 EST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Build Identifier: Version 3.4.2 M20090211-1700

ControlObservableValue and TextEditableObservableValue currently do not get notified when the respective property on the control is changed. In practice this means that these observables can only be used for model to target updates, but not from target to model.

This is probably due to the fact that SWT does not provide event types for these properties. I'm aware that this would be a major change in SWT, but having Observables which can monitor these properties would be extremely useful.

If it can't be done, it would at least be useful to add comments to the JavaDoc of these classes (and the corresponding SWTObservables methods) that the observables cannot track the changes on the controls.

Reproducible: Always

Steps to Reproduce:
1. Create an IObservableValue on a control using SWTObservables.observeEnabled(Control)
2. Call setEnabled on the control
3. The target observable does not get notified of the change
Comment 1 Yves YANG CLA 2009-11-10 08:50:44 EST
I think in API, you should call the set to IObservableValue, instead of the Control directly
Comment 2 Thomas Schindl CLA 2009-11-10 08:55:13 EST
Right there's no SWT-Event so no change can be progagated but please keep in mind that programmatic interfacing with SWT-Widget will NEVER lead to an event => you'd need to document such a thing on ALL WIDGET-Observables and properties.

1st side note:
--------------
And just as a side note if you want a SWT-Widget-API which provides you such a feature you can take a look at UFaceKit which delivers events no matter why it changed (but it is designed to be used for Form-UIs and doesn't provide the full SWT-API)!

2nd side note:
--------------
I had a discussion with Steve N. at the last EclipseCon about programmatic events and he was by then willing to add a special listener API which would have been informed on programmatic changes as well.
Comment 3 Tillmann Seidel CLA 2009-11-11 07:39:38 EST
Yves: that's definitely the way to do it, but not always feasable:
- It might be that not all the code accessing the widget is under your control.
- In a larger team it is difficult to make sure that all developers set the value on the observable and not on the Control. Bugs are likely to happen. 

Tom: NEVER is not true, it works for the TextObservableValue: setText on a Text widget triggers an SWT.Modify event. But it seems to be the only case where it works so you're right about the JavaDoc. The TextObservableValue is THE observable from SWTObservables we're using in 99% of the cases so I was mistaken to believe that its behaviour is normal and not the exception.

UFaceKit sounds like an good alternative but naturally I'd prefer programmatic
events to be included in SWT. Is there a enhancement bug for that already? Then you can close this one as duplicate. Otherwise it might be a good idea to leave this one open as a reminder.
Comment 4 Yves YANG CLA 2009-11-11 08:01:32 EST
(In reply to comment #3)
> Yves: that's definitely the way to do it, but not always feasable:
> - It might be that not all the code accessing the widget is under your control.
> - In a larger team it is difficult to make sure that all developers set the
> value on the observable and not on the Control. Bugs are likely to happen. 
> 

In XWT, we'll provide a mechanism to keep all used IObservableValue. In Declarative langauge, we don't care of it. It is managed transparently. But in programming, the developer can call XWT service to find the corresponding IObservableValue like:
    XWT.findObservableValue(Object context, Object data, String propertyName);

And then, developers can change its value with notification of Data Binding.

We need definitively this solution not only for Widget, but also for Pojo model data.
Comment 5 Matthew Hall CLA 2009-11-12 16:13:11 EST
We cannot detect a change automatically in DataBinding without a listener API.  Until this changes on the SWT side, the best we can do is to document which properties do or do not send property change notifications.

One thing DataBinding *will* do for you as of Eclipse 3.5 is fire a change event as soon as the change is noticed inside a call to an IObservable accessor method.  So you'll get a change notification eventually but probably not right away.  This could be short-circuited by manually accessing

(In reply to comment #4)
> We need definitively this solution not only for Widget, but also for Pojo model
> data.

It is doubtful we can solve this for POJOs for the same reason as for widgets: POJOs, by definition, are basically the same thing as JavaBeans but without a change listener API.  If you need events to fire from your pojo observables you should upgrade your POJOs to JavaBeans, and use BeansObservables/BeanProperties instead of PojoObservables/PojoProperties in your binding code.
Comment 6 Matthew Hall CLA 2009-11-12 16:18:22 EST
N.B. ControlObservableValue and TextEditableObservableValue were internal API in Eclipse 3.4 and before, they were removed in Eclipse 3.5 and replaced with properties.
Comment 7 Eclipse Webmaster CLA 2019-09-06 16:09:06 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.