Yes, that sounds good too.
Cheers,
Wim
On Tue, Mar 16, 2021 at 4:38 PM Matthias Paul Scholz <
matthias.paul.sch...@gmail.com> wrote:
> Hallo Wim,
>
> Thanks for the proposal.
> I am aware of delayed databinding, but you might be interested to hear
> that I have found another workaround in the
Hallo Wim,
Thanks for the proposal.
I am aware of delayed databinding, but you might be interested to hear that
I have found another workaround in the meantime:
I have "slipped in" an intermediate model between the CDateTime instance
and my wrapping widget.
The model is hosted by a class derived
Hi Matthias,
Another option is to throttle the selection. Databinding has support for
that. Try this snippet:
import org.eclipse.core.databinding.observable.Realm;
import org.eclipse.core.databinding.observable.sideeffect.ISideEffect;
import
Hi Wim,
I'm aware that the concept of an edit transction makes sense for the
graphical mode only where the user has some sort of "edit session".
But at least in that case I think there should be such a concept and the
API should provide a possibility to hook into it.
By the way, I wonder
Hi Wim,
Thanks for the quick answer.
Unfortunately, the simple version is no option for us, since our customers
are used to the graphical version for years now already.
A look in the CDateTime sources revealed to me that there isn't a real
concept of an edit transaction in the widget: the value
Hi Matthias,
It depends on how you use the widget. CDateTime has many faces. When using
the widget in its simplest form, there is no concept of Enter or OK. So it
means that databinding has to be different based on the style of the
widget.
[image: image.png]
Cheers,
Wim
On Mon, Mar 15,
Hi all,
For some years we have used the CDateTime widget in our RCP application
which works quite good. :)
However, we ran in some troubles lately: to get notion about changes the
user made in the widget, we use the databinding proposed by Henno
Vermeulen (see
