> > Now suppose I want to change it for all the classes. Real OOP would be > > to go upstream to the highest class definition in the class hierarchy - > > and there's none. You have a dozen of them, each with its own set of > > defaults (some of them far away from my taste). > > > > I guess it'll come down to writing a routine to scan my .vcx, cram some > > "Property=value" lines into memo fields and recompile the .vcx. > > For Grids, I think the Builder approach is the most appropriate (My 2 > BEF). Builder it will be, as it seems, or a wizard/builder pair. And it will have to write down few extra properties... still I think its very non-OOP - I want to have the grids I'd built last month and the ones I'll build in two months conform to the same rules, i.e. belong to the same class, and not to go clicking on them all day long just to achieve the same. Even a noninteractive builder (though it may contradict the idea of a builder) would have to go thru all the directories and all the scxes in search of grids of certain class in order to shape them up. Still I want to have a grid class with different defaults - when I issue grid.addcolumn(), I want to have the header to be of _my_ header class and default grid cell object of _my_ default class. Do I ask impossible? > Another > > guess: if in that way I create properties which never existed in some of > > the base classes, but will exist in my classes, no harm will be done - > > just there will be no code to react upon the change of these properties. > > Yes but if you add the Behaviour.property and instantiate it as a > Behaviour Class in the Init of the base classes, you could achieve this > by updating the Behaviour class only once, and copy certain values to > the corresponding values of the parent. This goes to my "watch this" mail directory. Worth remembering.