Terry,

In order to answer your question, it might help to know a little more about why you have three tiers. I myself use three levels, but for a very specific reason: The "bottom" tier contains my framework code. The middle tier can be safely experimented with w/o affecting proven classes at the bottom tier, while the top tier can contain project-specific changes.

If this is what you are doing, the following inheritance scheme works very well for me.

Consider three class libraries, Forms1.vcx, forms2.vcx, and forms3.vcx, representing the bottom, middle, and top tiers of the scheme. Now consider Forms1.MyFormBaseClass, which contains all of the properties and methods that I want to have in all of my forms in all projects. This would naturally inherit to Forms2.MyFormBaseClass2 (don't ever name two classes in different libraries the same thing!), and on to Forms3.MyFormBaseClass3.

Now I want "FormEdit", which inherits from MyFormBaseClass. Question is, from which library? The answer is to create Forms1.FormEdit as a subclass of Forms2.MyFormsBaseClass2. This achieves the desired affect of having all properties and methods achieved at the bottom level, while changes made at the middle level will still propagate "backwards" to the bottom level as well.

This "zig-zagging" inheritance, as I call it, offers the ultimate in flexibility and safety for your roll-your-own framework.

Hope this helps.