Hi Jess,

1. The developer shall be guided on the application of VFP OOP as it is vital, important thing to be understand especially on the part of new comers. IMHO, frameworks do not totally explain the intricacies of OOP. In frameworks, the OOP has been applied but its explanation is doubtful. That's why if a developer wanted to be in depth in VFP programming and buy a framework, he should understand and study the architecture behind.

It's really not the responsibility of a framework to explain OOP. There are countless books on the subject. The framework documentation should probably explain how OOP is applied within the framework, but that's not necessarily required. Of course, the framework should document the object model, class hierarchies, etc. No one has ever said that you shouldn't study the architechture of a framework. It's an excellent way to learn OOP, but not an introductory way. I'm sure your in-house frameworks benefits - directly or indirectly - from some things you & your staff learned about OOP from the frameworks you looked at. However, one of my key points throughout this thread is that you have to have a pretty advanced understanding of not just OOP, but also OOA and OOD, before writing a framework. That's why I cringe when anyone recommends that someone new to VFP writes their own framework.

2. We do not know the life span of commercial framework owning companies, and so the developer creates dependency on himself or themselves and not on others. As I have said to Jim Booth, dependency is not bad at all, but oftentimes, the developer tend to confine on what is packaged on the other product thus he/she stops applying his/her ideas as it is boring and difficult to know the nitty gritty of other's code. Dependency on others creates comfort and therefore the developer stops stretching his potential and work beyond the comfort zone.

You have some valid points here, but they aren't necessarily true. Many people buy commercial frameworks and take complete ownership of them by modifying them extensively. This means they'll probably never upgrade and have no dependencies. While none of the framework vendors like this approach - because it means there probably won't be any future revenue from those customers - it certainly is a valid way to use a framework. In fact, this is the case with two of the frameworks right now, VFE and MM. ProMatrix is basically based on Tastrade, but not dependent on it either.

We are developers, not end-users. We have variety of ways and tools to create quality software. 'Yours' maybe a lot better than 'Ours', but it's the same argument, we sold 'ours' because its looks and works different from 'yours'.

Using a commercial framework doesn't make you any less of a developer, which is what you seem to imply. If that were the case, then the same would apply to anyone who uses an ActiveX control as well. With ActiveX controls the developer typically relinquishes more control because most of them don't come with source and if they do, you have to be a C programmer to modify them.