Chris,
> I have a sub presenter and sub view pair that represent an object that is
> selectable from a list box. If I use model: to set the model when a new
> item is selected from the list I notice that the sub view flickers. Upon
> examination of the Dolphin code I see that refreshContents is called which
> in turn invalidated the entire view. I wonder if this is really needed,
it
> would seem that any sub views that are actually changed in a visible way
> should invalidate themselves. I suspect that what makes this refresh
> noticeable are my static text labels and group boxes which flicker when
> repainted. I can avoid the flickering by using another instance variable
> and not using model:, but it feels like a violation of the notion of MVP.
>
> Any ideas or comments about how I should handle this?
It's not really legal to use #model: on a running triad. With that said, I
think the restriction could be removed if trigger wiring (at least that
specific to the model) were established in #model: rather than in
#createSchematicWiring. There would still be the problem of "pushing"
changes into the views, which is what #refreshContents is trying to do.
IIRC, this is necessary because many of the native widgets have their own
copy of the (usually as text) data to be displayed, and that copy has to be
altered when the Smalltalk model changes due to programmatic causes - if
"the GUI does it", then Windows is generally aware of the change.
Take a look at my PaneHolders package (comments/suggestions are always
welcome), and the DynamicMVP page on the Wiki.
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]
Locked
