>>Thanks for your responses; I was beginning to wonder if anyone thought this was worth replying to... I guess using my example through everyone off a bit. I was interested primarily in knowing whether the logical relationship between the class and the instances was such that the class should contain behaviour/code that was shared and the instances only what was relevant to it's particular environment. I was really trying to draw a line in the sand regarding what to code in an instance as opposed to in the class. Dan mentioned that I should put the AddProc in both buttons as this was only relative to the form. I think I agree, but where is the line drawn? Does that mean that it would be ok to put it in the class if my classed forms always contained that proc? Or would it never be ok? Again, that's just an example; looking for concepts really. I'm trying to develop apps with the mindset of relatively easy mainenance as well as solid functionality. It gets a bit fuzzy in reality as to
>>where to put what sometimes...
>
>I should add that, in my case, when I speak of the "class" above I'm talking about what I consider my "App" class. I have "Base" class libraries, "App" libraries which are derived from objects in the Base library (and additional if needed) and then instances created from the App libraries for anything used in a specific application... I'm sure that cleared things up! :-)
>
>Renoir

Well, as I said earlier, it depends. If you plan to use this button more than on just one form, then subclassing would be fine, so you would not need to repeat the same functionality all over again.

Sometimes, however, you would not subclass to not make too deep hierarhy and keep your libraries light.

For instance, I suggested to add some conditional piece of code in our baseform class. For me it sounded silly to repeat it all over again in all my apps.

However, as it was for most of my suggestions, they were not implemented...