>>>>>Should a newbee start developing with the basics of VFP, or first of all choose a framework and start developing with that framework? In other words, what are the pros and cons for a newbee of working with a framework from the beginning? This is a recurring theme, but a controversy that has never been settled well, so opinions please.
>>>>>
>>>>>Here's my opinion:
>>>>>I made the oo-jump (from FoxPro Windows to Visual FoxPro) with Visual Maxframe. Later I had to learn Codebook. Neither VMF, nor Codebook made me happy. In my private projects I abandoned both frameworks and started to develop with the basics of Visual FoxPro. Only after I learned the basics I had enough knowledge to understand what VMF and Codebook were about. The point is, developing with a framework is fine, but only until something goes wrong. At that moment you have to dig into the sourcecode of the framework, which, by nature, is completely vague to a starter. You're lost in (caught by) the framework.
>>>>>
>>>>>But I'm not saying here that frameworks are worthless. I only want to warn newbees that it's risky to choose a (costly) framework now (based on what knowledge is that choice?), spend a lot of energy to learn the concepts of the one framework, and later having to admit that this did not imply that learning Visual FoxPro itself could be skipped. No, I think it's better to first learn the basics of Visual FoxPro and only then eventually buy and learn a framework, eventually...
>>>>
>>>>Should a person learn everything about internal combustion engines to drive? Should you start to build a car from scratch or go and buy a working engine?
>>>
>>>It's not really a good analogy, Mike. We are the developers. When something goes wrong, we don't turn our code over to a serviceman. We have to be able to fix that engine when it needs fixing. If we don't know anything about how an engine works, how will we be able to fix it when we need to?
>>
>>As a kid I never hesitated to fix my bike, but I never built one from scratch. A bike is a framework of sorts.
>
>Sure, me too, but really, what's simpler than a bike. Everything is right out there in the open. VFP is different. It's closer to the automobile engine, and I have to admit, when my car's engine has a problem, I don't even try to fix it, I take it to the pros. When it comes to my car, I'm an end-user, not a developer.
>
>I'm not talking about having to be able to build a framework before being able to use one but I really believe that a developer will even get more out of using a framework if he/she has a good working knowledge of VFP first.

I attended several week long vfp classes including those given by Flash (YAG) and MEI (George Goley), along with many others. Learning VFP is perhaps subjective. How do you learn it and when do you know what you should know to be successful?

There are varying degrees of success with any undertaking. If you make money with VFP and have limited knowledge then you may be satisfied. On the other end would be the person so engrossed with the product that he/she only has time to approach it from an academic viewpoint.

One thing we concluded about learning VFP. If you examine at least one framework implementation from a commercial vendor your understanding of VFP will be greatly enhanced. You will quickly see how the nuts and bolts go together and envision how to go about solving problems. At that point you could create your own framework but why? You could use what you have and modify it as required by your own needs.

Now I could also write my own software development tools but that would not be productive. I like the ones I use. :)