Bugfix ChoicePresenter>>nilChoice

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

Bugfix ChoicePresenter>>nilChoice

Carsten Haerle
The ChoicePresenter>>nilChoice method doesn't update the view, so when one
changes the nilChoice after the view has been displayed the display is
wrong. The fix is below:

!ChoicePresenter methodsFor!

nilChoice: anObject
 "Set the choice that will be used to represent nil in the receiver to be
 anObject."

 nilChoice := anObject.
 self updateChoice! !
!ChoicePresenter categoriesFor: #nilChoice:!accessing!public! !


Reply | Threaded
Open this post in threaded view
|

Re: Bugfix ChoicePresenter>>nilChoice

Blair McGlashan
"Carsten Haerle" <[hidden email]> wrote in message
news:bv8c7u$ps7$07$[hidden email]...
> The ChoicePresenter>>nilChoice method doesn't update the view, so when one
> changes the nilChoice after the view has been displayed the display is
> wrong.

Thanks for the report and fix. I suspect the method was only intended for
initialization before the view has been opened, but this is not made clear
in any way and there is no particular reason why it shouldn't be possible to
change the nilChoice later. We'll include this in PL4.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Bugfix ChoicePresenter>>nilChoice

Carsten Haerle
I just discovered, that the "fix" I provided has as negative effect on
the development system:

The Method Aspect class>>choice:from:andNil: first sets nilChoice
before choices, raising an exception (which is caught and ignored).
You can see this for example in the view composer: you cannot see the
arrangement choices of a view, if the parent has a layout manager.

Previously you could set nilChoice to something which is not contained
in the list, because the method didn't try to update the GUI. My
change ensured that you could also set nilChoice afterwards, but
introduced the limitation, that you cannot set nilChoice to something
which is not already in the list.

So for my project I did want back to the original implementation and
ensured that I always set nilChoice before setting the list and never
change nilChoice afterwards. The other solution would be to always
ignore bad nilChoices (those beiing not in the list), but maybe could
introduce hidden bugs.

Regards

Carsten Haerle

"Blair McGlashan" <[hidden email]> wrote in message news:<bv8r41$pj0uv$[hidden email]>...

> "Carsten Haerle" <[hidden email]> wrote in message
> news:bv8c7u$ps7$07$[hidden email]...
> > The ChoicePresenter>>nilChoice method doesn't update the view, so when one
> > changes the nilChoice after the view has been displayed the display is
> > wrong.
>
> Thanks for the report and fix. I suspect the method was only intended for
> initialization before the view has been opened, but this is not made clear
> in any way and there is no particular reason why it shouldn't be possible to
> change the nilChoice later. We'll include this in PL4.
>
> Regards
>
> Blair