[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:
        disableAll
                self radioButtons do: [:each | each disable]
and
        enableAll
                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:
        model: anObject
                super model: anObject.
                self onValueChanged
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
been doing.

--
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> 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.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]