On Wed, Sep 11, 2013 at 08:54:13AM -0400, Bob Arning wrote:
> I got into the state where I could not open a FileList and tracked it
> down to the ToolBuilder default having retained some state from an
> earlier error building a new widget. In particular, the <parent> ivar
> was still pointing to some previous SystemWindow and gthat caused error
> when trying to create the buttons on the FileList.
>
> In ToolBuilder, one could add an ensure: to see that parent always gets
> reset:
>
> buildAll: aList in: newParent
> "Build the given set of widgets in the new parent"
> | prior |
> aList ifNil:[^self].
> prior := parent.
> [
> parent := newParent.
> aList do:[:each| each buildWith: self].
> ] ensure: ["<<<<"
> parent := prior.
> ].
>
> but I guess a better question is why Toolbuilder default doesn't
> automatically return a clean builder?
>
> Cheers,
> Bob
Good question. It was probably a matter of design style. Every Project has
a UIManager, and that UIManager has its own ToolBuilder instance. That has
a nice feel to it, and it makes the roles of these things seem more clear.
It also avoids the need to figure out what kind of ToolBuilder to create
each time time you use one (normally a trivial concern but possibly more
complicated when entering one kind of project from another).
On the other hand, keeping transient state in the instance variables in not
a very good thing for the reasons you found, so I'm not sure the best way
to handle that. Another approach might be to reset the tool builder prior
to using it to build something. Two processes would not be allowed to share
one tool builder, but that is implicit in the design already, so it is
similar to dealing with a stream in that respect.
Dave
Locked
