>David,
>
>If you are going to create the from the way you say you will, what benefit does the class stuff give you? What do you gain by saving everything off as a class then reassembling it as a form again?

As far as I know, there is no convenient way, under the form designer, to display parent method code for any of the contained controls (that are not subclasses). Apparently, the superclass utility you referred me to gives one this capability, though I have not had a chance to test it yet. Obviously, somebody thought that being able to at least view (if not edit) parentclass code was of value...or why spend the time writing such a utility?

Saving the controls as classes opens them up for inspection (and even editing) by the Edit ParentClass Method utility (which, by the way, I can only get to appear by first running the Class Browser).

So, I'm not particularly interested in saving my controls as classes, per se, I just want the means for inspecting code up the class hierarchy to be more convenient when I need to do it. At the same time, I can see how subclassing each of the controls on a form, just to get the access I desire, runs counter to the development methodology you're selling. Still, convenient inspection of an object's parentclass' structure is surely a desirable development tool, even within the context of that methodology.

>
>Why not just create the form and be done with it? Then later, when you have a better handle on OO and take advantage of the value of inheritance you can redo the form using classes to provide the behavior.

Actually, I have three instances of a form class that works with orders. Some of the commonality is embedded in the form's controls (which I have to believe is a fairly common attribute of customized form classes). So, since the controls have custom code and default property values, I need to be able to inspect them as I develop the separate instances in which the class expresses itself at run time.