Terry,

Well, I had a nice detailed response typed out, but lost the UT yesterday and it was gone, so here goes again:


>> Thanks for the response. So FormEdit exists in your level3 library with parent in level2. <<

OK so far.

>> Yes my 3 levels are for the same reasons as yours
seem to be.<<

Still OK so far...

>> If I put FormEdit in level3 and subclass Forms3.MyBaseFormsClass though it also gives FormEdit the qualities you mentioned. Which
is best is my question. Once a person has a Forms3.MyBaseFormsClass on level3 library, should one not bypass it by subclassing back to level2? <<

The answers to this question and your remaining questions come down to making a decision and then going with it. When I first came up with 3-level classes, for the reasons we both have, I wrangled with this. I finally realized that, mathematically, the number of possible inheritance chains is infinite once you begin zig-zag inheritance. Therefore, a design decision had to be made.

So we aren't so much deciding the best way to do this in an absolute sense so much as we are finding the best way to get the flexibility we want, and throwing away everything else. So it helps to go back to the example.

Forms1.MyFormBaseClass (the parent of all forms throughout the framework)

Forms2.MyFormBaseClass (this can be modified safely to affect all forms in the framework w/o hitting proven code)

Forms1.FormEdit (inherits from Forms2.MyFormBaseClass. Contains all framework code and properties that define an editing form. In my case, it just contains a toolbar manager)

Forms2.FormEdit (this can be modified safely to affect all editing forms in the framework w/o hitting proven code)

Forms3.FormEdit (one copy of this in each project. Actual forms are instantiated from here)

By "zig-zagging" only from level 2 back to level 1 you achieve all of the flexibility you need, and more than most need.

The big advantage of this is that two like-minded developers can share a framework and hand improvements back and forth to each other via the middle layer. That's really why I did it.

Some other points:
There is only one copy of Forms1.VCX and Forms2.VCX, common to all projects. There is a copy of Forms3.VCX in each project directory. Of course, the same applies to Controls1.vcx, ActiveXControls.VCX, and so on.

In practice, I have found that I never modify the project-specific libraries at level 3, though I keep this structure just in case. It seems that anything worth doing for one project is always worth putting into the framework at the bottom level, with some options for turning it off and on.

One thing worth mentioning is that this works for me because I have a flattened form heirarchy, using only 3 form classes for just about everything. These are FormEdit, FormReport, and FormBatch. I don't buy into the philosophy of creating FormEdit, FormEditFlat, FormEditOneToMany and so one, it offends my sense of the general-purpose.

Finally, it wouldn't be fair not to mention that this also works because I have comparitively little code in my forms. The MyFormBaseClass contains hooks to call drop-on objects (sort of fake ActiveX controls, if you will), so when I need to modify a form, I make up a custom class and drop it onto the form or form class. So far I've only need two of these.

Finally, I myself bought a commercial framework about 18 months ago, and made my money back on the guinea-pig project (I think my testimonial is still up at www.promatrix.com). After I learned everything I could from it, I became impatient with it for many reasons and returned to my old power-hungry do-it-yourself habits.

Please excuse the long-winded response, but nobody has ever brought up three-level class structures before, and it is something I'm very happy with.