>>Excerpts from and links to the existing case studies, plus what JohnK comes up with, plus links to M$'s articles on VFP vs Access etc. Should be good enough to start with. I'd also like to see a page stuffed with things that make M$ marketing people drop their jaws with "wow, we didn't know VFP can do _that_!".

>Hiya Dragan ---
>
>I hope that people realize that if we do start this thing (VFPDA) it works both ways: Not only should we promote the use of VFP but we also have to find ways to enhance and ensure the professionalism of the VFP developer community. I could tell you some horror stories about projects where the developer(s) was suipposedly a VFP guru and .... well, you know.

Just a small question to this: were they UT members?

The hidden bit of malice in this question is pointed to the fact that it's not an art to be a good professional when you have a great tool - it's much more an art to be a bad one with the same tool.

Nope - wrong point (but left it anyway, just for fun). I wanted to say that we're already doing our part in alleviating the professionalism in our ranks - remember the many threads about better GUI, elegant solutions, contracts, better ways to do things, etc etc. We're helping each other to become better professionals. I can't be responsible for any freelance street fox, unless the person comes here and asks a few questions.

Horror stories - mind you, I've read some of the code... imagine a guy taking money for an app (in FP DOS) where he had a Read after each Get, and listed them all in the same Case construct, where a global variable decided which Get will be the next one. Needless to say, in the beginning, user sees only one Get, then performs the Read, then user sees the next Get...