>Peter,
> I understand many of your criticisms of VFP. I have encountered
>many of the bugs before in VFP. I have pulled my hair out extensivly
>in trying to decipher these quirks. I also come from an MFC environment
>and had a suite of programs developed of which some were in C++. I
>eventually converted the C++ sections over to VFP because of the
> database tools in VFP. I don't know why someone doesn't come up (at
>least that I've seen) with extensible query tools for MFC. I was using
>Codebase before and they had taken way too long to come up with the
>activeX version of their C++ controls. I find that it is so much easier
>to develop in VFP once you get over the learning curve.
>
>Any others have comments?
>
>Gary

I doubt that MS will develop the VFP database engine separate from VFP for consumption by C++. Too bad, and I think MS would be loosing out. Mentioned elsewhere on this thread, the more likely candidate would be for VFP as an OLEDB component. This would be ok, and just half a step down from true, native support for C++.

The C++ language was just recently ISO standardized, and has a whole bunch of cool features that either weren't included in VC++ 5.0 because of their speculative nature or because of their not being developed yet. STL, which implements containers (stacks, queues, associative maps, etc) and standard algorithms for those containers, is currently implemented in a limited form, but looks very exciting in the 'standard'. I guess I'm just fed up with the quirks of VFP (and the gut feeling that its nearly impossible to master VFP because of the quirks). I knew C and C++ well before I knew VFP and the learning curve was shorter for C++ fore me. It just so happened that I was in high-school 'flipping burgers' and a friend offered me a job doing VFP. How was I to resist a programming job???? :-)

Peter