>You're probably further down the road. What you do is what I'd like to do if only I had the time to clean up the stuff ... :)

Read carefully, Marc:

>>In OOP world, I'd have empty subclasses

"I'd" stands for "I would" - I mean I'm not deeply into any app yet, so this is all just a plan, so far. Well, one of the first things I've learned of OOP is that's it's 70% planning, and the rest is coding & testing. So, I've taken the slow pace. Anyway, this was the way we operate in FPD, and I'm deeply in self-compatibility issues for many years now, and once we finally migrate to VFP in production, it will get deeper. Knowing the usual culprits in advance helps a lot :).

>> of most of the classes of the framework in a classlib in the app directory, and using them as intermediary, change what has to be changed in this specific case, and, once it lives, see which changes are candidates to be propagated back into original classes (i.e. if other apps would benefit of the new behavior). In the current phase, all apps are using the framework (or what is ready of it) off the same directory