>>>If you're in a situation where you need to develop multiple VFP applications a framework like this can really save-the-day. Now if you're doing just one project - well...then it all depends on the project of course. But the framework has so much stuff built into it and it can save you so much time that the learning curve is worth it. VMP is a framework, not really a RAD tool - which is what is nice. Don't want to hurt anyone's feelings - but one of the others I was forced to use one time was visual promatrix - and for me that thing has horrible. It was more of a RAD tool that was designed for people who really don't know VFP - and it broke many of the conventional rules of VFP programming...and good heavens don't ever step out of that box or you're SOL. True there is a promatrix community, but you'll notice that most of those folks don't exist in any other VFP community either. Everytime I think of promatrix my blood boils remembering that they didnt want you to use comboboxes - they wanted you to use their stupid textbox and a button next to it with an immage of an arrow on it.......aaaahhhh!!!
>>
>>I agree with both of you, paradox as it may be.
>>
>>Any tool out there is excellent for what it was designed for, and most of the VFP frameworks were designed to help their authors in their work. Help, among other things, includes workarounds for bugs, tools for common database tasks, GUI candy etc. Some did develop into just a framework, i.e. a set of tools, some into RAD tools, some (and I think VFE woudl qualify as one) into both.
>>
>>Now whether a framework will help you or hinder you, is a matter of how similar is your task to what authors were doing when they were creating it. It will still do swimmingly what it was designed to, but if you need to push it to do something else, it will resist.
>>
>>And VPM is an excellent example of the latter - it had its set of standards, and if what you were doing anything within those standards, things went fine and you didn't really need to know too much of Fox to crank an app. At the first curve beyond that standard set lay trouble. I hated it just with the passion that your words describe. I had to fight it all the way. I had to dig deep into its code to see where I can plug some non-standard behaviors, had to write code to have a non-destructive conversion of one version to two versions later - as we skipped one decimal there. And the code under the hood was FPD code, ported to OOP until it worked. Oodles of public variables, prefixed S (for system), and my predecessors on the projects thought that's mandatory, so all (ALL!) of their variables were prefixed just the same.
>>
>>I admire Hank Fay for staying with it so long. I wouldn't have the nerve. To think that I once turned down a job for just three reasons: they offered ten K$ less than I asked, 2) the offices were a nearly windowless cubicle farm in a glass-and-concrete cube with smoking area seven floors down and you had to wear a leash to enter and 3) they were using VPM. While I could ignore the first two points if the work was interesting enough, with the third it wouldn't be a joy.
>>
>>That VPM was surely something, if I still hate it after thirteen years :).
>
>
>Many moons ago (as you would say) I worked for company which had purchased and tried every major VFP framework available back then.
>Owner/Lead developer spent months and months studying every and each of them in details only to discover that NONE of them would
>let us or help us do what we were trying to do. With large user base installed (in DOS days) new VFP application should have been able to at least vaguely resemble old one in behaviors and functionality. No way Hose! You could have all bunch of nice layers, tears, encapsulations, abstractions and what not, but you could not make dummy lookup field pop up search form by pressing F9 for instance, which all our users knew by heart and expected to still have in new app.
>Things like that, some big some small in our case ruled out more or less ALL of them at the end.
>
>Finally, what paid off was exactly that extensive research we put in them. We picked up many good concepts/ideas
>and used them later to create our own frameworks and solutions. Kind of like in that story when father to teach his son a lesson, convinces him that there is a huge pot of gold hidden somewhere in a vineyard - all he has to do is digg it out!
>So eager gold-digger son digged and digged and digged for days and days hoping to strike that pot of gold,
>whereas gold came all by itself but long afterwards when thoroughly digged/weeded out vineyard produced generously
>at the end of the year and they sold its crop for good money... (Metaphorical pot of gold)
>
>So my general opinion on frameworks is as always;
>
>They are all very good, Of course everyone should use them!
>To learn ;)

Learn from it, yes. But it's not an efficient way of learning. Also one gets influenced by the norms of the author(s). Those norms might be okay, but perhaps they are not okay.