ValuePresenter>>value

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

ValuePresenter>>value

Ian Bartholomew
Not sure if this is classed as a bug or just an idiosyncrasy but as it has
bitten me a few times (and might be easy to fix *) I thought I'd mention it
again (it has been brought up before in the newsgroup, albeit some time
ago).

Some ValueConvertingControlViews (ScrollBar for example) fail to update
correctly when changed programmatically if something listening to their
#valueChanged trigger attempts to obtain the current value of the widget.

The chain of events (!) is

Update the ScrollBar's NumberPresenter using "aNumberPresenter value: 123"
The NumberPresenter's model is updated
#valueChanged is triggered
The NumberPresenter's view (widget) is updated

If a method responding to the #valueChanged event evaluates
"aNumberPresenter value", to get the ScrollBar's new position, then the
ValuePresenter>>value method helpfully updates the model from the view
before answering a value. However, as can be seen from the sequence above,
the widget is still showing the _old value. The effect is that the model's
new value is always overwritten with the old, original value and therefore
nothing ever changes.

It's easy enough to work round - just use "aNumberPresenter model value"
instead of "aNumberPresenter value" - but it would be nice to have one less
thing to remember <g>, especially as the two statements would normally be
interchangeable.

Ian

* but I don't think it will be without other subtle side effects :(