>Hello,
>
>In his (very good) book "Advanced OOP for VFP" Marcus Egger preaches that the best reuse of classes would be to share them over all your applications. We find this a nice idea but practically impossible to execute because you would influence all your projects by each change of a class (also those apps you do not want to touch anymore). We ourselves copy our framework with all subdirectories, classes and files into a new separate directory at the start of each new project.
>Is there anybody who has some more ideas on this ?

While I haven't been in charge of this under VFP, I've been maintaining and developing the common-library stuff for the whole company, a while back in fpd2.6, and the rules should be the same. Actually, in OOP it should be easier, because you can play with subclasses.

The principle would be obvious: there is one master copy of all the common stuff; once you decide something needs to be changed in some of it, make a local copy (local to one single app for one single customer). Test it, watch for side effects, propagate to more locations, and if it proves to be right, include in the main library and delete local copies.

Now instead of a local copy of a routine, you'd have a local subclass of a framework class. In the end you may want to redefine the framework's upper class behavior, or to include this subclass into the framework's class library. The point still remains the same: try it locally, and then try it there where you expect the changes may do the worst damage - if it still works, it's a candidate to be included upstairs.