[bug] RadioButtonSetPresenter #enableAll and #model:
RadioButtonSetPresenter in D6 had #disableAll fixed in PL1, but
#enableAll still needs the same fix (as of 6.02).
Before seeing that change, I had already fixed them using:
self radioButtons do: [:each | each disable]
self radioButtons do: [:each | each enable]
I noticed that the patch had changed it from "self disable: each" to
"self disable: each name". Since it already has the actual RadioButton,
seems simpler to just use "each disable", rather than using the
radioButton's name to find the radioButton, so that it can then disable
it. Or is there some compelling reason to do it that way?
Also, I overrode #model: to be:
super model: anObject.
so that after changing the model, the radioButtons would display the
current selection. Should this fix get incorporated?
Is it accepted practice to change the actual model (not just the value)
after an MVP triad's initial setup? It's something that I seem to have
Bill Dargel [hidden email] Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105 USA
Re: [bug] RadioButtonSetPresenter #enableAll and #model:
> Is it accepted practice to change the actual model (not just the value)
> after an MVP triad's initial setup? It's something that I seem to have
> been doing.
OA has become more accepting over time. AFAIK, DocumentShell has
_always_ done it. However, if I can avoid it, I do not change models
late in the game; instead I use a PaneHolder or variant of same and swap
out entire triads.