>>We have a framework for general stuff. If we improve it goes with the next update, if we extend we add compiler switches so we can controll who is getting what.
>>
>>(The switches control #IF #ENDIF sections)
>
>Now, that might be an interesting way to do some customizations.
>
>On the other hand, I was thinking that some customizations may even require different data structures, so I believe not all customizations can be accommodated.
>
>>We have a framwork up to 6 levels deep.
>
>6 levels of inheritance, you mean? Now that looks like a lot...

not realy

first level a simple copy of bases classes
second level basics (IO, report control, settings store, basic grid functions etc )
third level (first to create an app) basic handling of databases (open / close new backup) based on standard tables
fourth level introducing of a database meta system. I use a meta database to create all tables fields relations etc, database engine (not in DBC container) use this for all stuff
fifth level extend meta with user and some common but not overall features
sixt level "interface" that exposes the classes of the other levels to the app

Datastructur outside the meta is app specific, so this need to be discussed with every custumer (not all of them like there databases to be changed) We run sumetimes several vewrsions on one custumer, because he is not willing to set a old database to a new version. But this is simple a matter of economics. If he find it cheaper to pay me for mainting n versions then to code a translater from old to new data structur I'm fine. (Maintaining the old one is less exiting but pays better. Every change in both versions is payed at least twice. And the maintenance plan is double too ...)

Our custumers do mainly the same thing - one is the contractror of the other. They like to do the same stuff but from different POV. So a lot is the same but somewhere there is always a differnce. So we have decided to do all above meta level special to each app. To tricky to generalize.

HTH

Agnes