>>The bottom line is this: MS's own people will tell you that the market that VFP plays in is not growing. Is VFP retaining it's user base numbers??? It may very well be. But, it is NOT GROWING...
>
>You talked about xBase marketshare and VFP marketshare. Which one are you reffering too. As for MS's own people: I've heard too many CRAP comming out of MS's own people. I've got no reason to believe them when they say something I can't check, Esppecially when such information comes from a third party like you. I don't have to point out the dozens of messages regarding the death of VFP, do I ?
>

Walter, I'd be more inclined to trust John's and Microsoft's insights here. I don't base this solely on someone else's statistics, or an overwhelming religious attachment to VFP, with a corresponding desire to see it succeed; it's based on what I see in the local marketplace.

Yes, the number of opportunities locally for using VFP as a development tool has increased numerically. The rate of growth for VB and Java application development opportunities, only a small fraction of these being clearly data-centric, where VFP would be a better choice IMO, far exceeds this.

While I think the world of VFP, it's not the right tool for all jobs, and it's clearly the wrong tool for many. You can develop web-centric applications with VFP as a basis for your application; but if you intend to deploy on platforms that preclude Wintel architecture, it's not the right (or in most cases, even an available) choice. VB won't work there, either.

VFP is precluded when the targeted system is a CE host without something like WTS sitting behind it. Here's a Wintel platform which just doesn't offer VFP as an option - you have essentially two choices - VB or VC++ - if you want to
use MS development tools, you'd better know VB or VC++.

VFP is precluded when you need continuous, low-level access to the metal and low-level Win32 layers. Christof has done great things with his STRUCT class as far as exposing low-level structures via VFP, but he very clearly points out that it's not fast enough to compete with other products with stronger native low-level support. In many cases, I don't think VB is the right choice, either, but I don't want to bring the issue of VC++ as "the best" general application development language for Win32 platforms in to muddy the waters.

VFP is a horrid choice if you need to do significant amounts of linked list manipulation. This is a lot of the market I write for since I work on logistics problems involving routing and packing. Since a fair chunk of it is data-centric, you could kludge up something in VFP to do the task, but I'd bet that if performance of route planning tasks was the driving mid-tier business logic, VFP would be far from the best, or even a viable, choice, of the principal development language for the problem, even with COMponentization.

VFP is precluded if you want to write ActiveX controls. Period. End of discussion. Just about the only place I develop QUAD with VB by choice.

>John, you're making a fool out of yourself again.....
>

Perhaps he's not the only, or worst, offender in this case.