> > >>>I have designed my own, quite efficient and robust application > framework... I was just wondering how all you folks in the VFP community > have been dealing with using the same framework for different > applications...do you use a wizard to create a new project? Copy the > framework to your new project directory? Or just reference the same set of > VCX's and PRGs for all your apps?? We're deadly curious! > >> > >>My 2 cents... > >>We copy the main PRGs and a few other items (login, user Info, Main Menu) > to the new project. I have a set of base libraries/classes which (as Gary > said) are never deleted. They're mostly my basic controls with colors, > BMPs, etc. set, plus a few items like my favorite Interactive Change > text/combo/grid control Any changes in these at the project level is > simply subclassed into a project VCX. Any really neat ideas we come up > with are (very carefully) added to the base library. We've found that if > we're careful with default values on user-added properties that this works > well. > >> > >Hmm...everyone seems to have different ideas about how to they want to use > their frameworks... Many of them I have considered myself. The only > question is, how often do 'fixes' or 'additions' to the global class > libraries propagate new errors into older applications, which will appear > on the next compile? > > Well, obviously, it depends on the type of change. But I would imagine > that if you follow the 'add/never remove rule', that will solve quite a > bit. And if your framework is as carefully thought out as you say, you > should be able to predict, with some level accuracy, how updates will > affect applications already in production. > > I guess the most important thing is being able to recognize the difference > between a tweak and a mod. If the behavior of the child object is > significantly different from the parent, perhaps it should be a mod and > copied to another app-resident VCX as opposed to a tweak which could remain > a sub-class. One term that you hear quite rgularly in my office is 'Regression Testing' -- making sure everything that the change might have affected is tested thoroughly. Even if the change might have come close to it but not really touched it, its tested. This ensures that the application is quite widely tested, but it doesn't check every possible thing that could go wrong. Regression Testing is essential when you make _any_ change to the base classes. /Paul