Chris
You wrote in message news:bfa1cp$ch4or$
[hidden email]...
> We have encountered an odd occurrence when setting a BooleanPresenter''s
> value in onViewOpened and then acting upon a changed event. See the
linked
> package for an example of the issue.
>
> In ValuePresenter<<value the line
>
> self view notNil ifTrue: [ self view updateModel ].
>
> seems to cause the model to refresh itself from the view, the problem is
> that the model as not yet changed the view by the time our event gets
> triggered, so it ends up resetting the model and returning that new value
> (not the value we set it to)....
This sounds very much like the issue "ValuePresenter>>value resets old value
if invoked from #valueChanged event handler" reported by Ian Bartholomew in
his newsgroup posting entitled "ValuePresenter>>value" of 23rd November
2000. As he suspected it is easy to "fix" by removing the line you mention.
Here is Andy's comment from the bugs DB:
"General thought is that the correct solution would probably be to remove
the line: self view notNil ifTrue: [ self view updateModel ]. from
ValuePresenter>>value. This would at least make it symmetrical with
ValueConvertingControlView>>value and, as far as we can see, would only have
an effect when trying to get hold of the contents from a text presenter that
was currently being edited. In such circumstances this would result in the
old pre-edit copy of the model being answered. Also, this doesn't
necessarily seem incorrect when the change hasn't been committed back to the
model at this stage anyway. If this *was* important then the programmer
could force an explicit #updateModel before accessing the value. ..."
We did indeed apply the change, but found it broke many things; it has the
side effect of breaking use cases where the current value is needed and
queried from the presenter, but the model has not yet been updated. The most
common example is where a TextPresenter is associated with a view that does
not have the 'updatePerChar' attribute, but where the value is tested
against during #queryCommand: processing. For example removing the model
update prevents the OK button in a Prompter from ever becoming enabled if
its validationBlock requires that at least some text be entered.
Our analysis at the time was essentially that it was probably right to
remove the update of the model, and that cases where the current view value
is required before the view value has been committed should probably use a
mechanism like updatePerChar, or access the current view value directly.
However we considered that in addition to breaking a lot of existing code
that this would make the MVP framework more difficult to use and understand.
On balance we decided that it was better to make the common case simpler and
live with the quirk, so we eventually closed the issue with no action.
>... Our workaround was to avoid
> ValuePresenter<<value by getting the value from the model directly.
Which is indeed the workaround must use from ValuePresenter #valueChanged
event handlers.
>...
Regards
Blair
Locked
