>>I don't want a bunch of useless objects in memory. I find it absurd that I can change their properties but not remove them. If this is really how it works, and I'm not missing something obvious (which I often do), I'll go back to my old way. I'll lose the power of subclassing, but I wasn't going to use it anyway when I subclass the classes in wizstyle, which I don't modify.
>
>
>You may find Microsoft's design in the Wizard classes to be NOT the design you want.
>
>IN which case you have to abandon Microsoft's classes, or COPY then to a different name, remove the objects you don't want from those classes and THEN subclass your copy.
>
>
>Using someone else's class designs means you have to accept what is in their parent classes, you cannot remove objects from a subclass that are in the parent.
>If you could, there would be the opportunity to totally break the collaborations among the objects in the parent class. In this case you could break your subclass and have to rewrite code to make it work.
>
>
>Remember, the class hierarchy is a Gen-Spec hierarchy too.
>From generalised classes at the top to specialised classes at the bottom.
>
>If you (or in this case Microsoft) put a lot of specialisation in at the top of the hierarchy then the classes become less reusable.
>
>From a programmer using the classes' POV, the classes become more rigid and force you into working in the was the designers chose, with the visual layout the designers chose.
>
>
>In that case you have a few choices:
> Look for another framework to base your development on
> Modify the Wizard classes and have it use your changed classes
> Write your own framework to do just what you want
That makes more sense to me. I will end up copying the wizstyle classes as needed and changing their names, as I have been.