>>The point is, for many IT managers VFP is DEAD!
>
>One of my current contracts is exactly the same, and there seem to be many similar ones around these days.
>
>HOWEVER...
>
>Another pattern I've noticed is that as soon as I start working on one of these "eliminate your own job function" contracts, it ends up having the opposite effect, as the clients learn the value of FoxPro. The simplicity of new development, easy RAD, and other benefits, create a feeling that FoxPro is good for "quick and dirty" database tools, if nothing else.
>
>I think that VFP is definitely headed towards the "legacy" language scrapheap. MSFT markets it (when it markets it) as "the best tool on the planet for maintaining legacy xBase applications". I.T. folks, especially, aren't going to be jumping on the VFP bandwagon if they're not already on it.
>
>But it's not quite the End Of Days yet. VFP still uses all the most current technological tools available, still has one or two advantages over FB (not counting inheritance, since that's gone in 7.0), and a skilled VFP programmer can still kick a skilled VB programmer's ass at database development. I'm still putting a lot of time into learning new VFP techniques, and I think I can leverage my skills in VFP for a long time to come. I honestly doubt MSFT would flatly LIE about it's support for VFP in the near future. They'll give us a good 2 or 3 years' notice before dumping us, or they'll incur the wrath of the dev community - VFP and otherwise - for playing such games with people's livelihoods. They're not that stupid.
>
> - John Pinter

I don't know who said "The developer community can only handle so much ineptitude before it is construed as a conspiracy". I only wish the skills that I have worked so hard to acquire would be taken more seriously in the Corporate IT world. We just don't get enough respect. Everytime someone comes up with an obscure snippet about Visual Foxpro's continuing role in the Visual Studio Development suite, I feel like a dog begging at a table for scraps!