>Jim,
>
>About all I can say to that is: With VFP focused on mid-tier, it will ever be thus.
>
>Which is unfortunate, because many product vendors take the approach that their product *will* best the competition some day soon. Clearly MS does not, leaving the small/medium business to VB+ADO (now that it exists) and leaving VFP for the Enterprises, *IF* they elect to use it over other competitors.
>
>Cheers,
>
Jim,

VFP's architecture is at the root of VFP's problems with COM objects and its UI is hampered by the fact that none of its controls are actual windows objects. Yes, further development could move the bugs around, but I don't believe the bugs will ever be gone completely. Look at the last three releases. Each one "cured" certain bugs only to introduce new ones.

To take VFP to the place you would like to see it go would require a complete rewrite of the whole thing. Why would MS do that when they already have VB, VC++, VJ++, Access, etc.etc.etc.? Why would any company invest a large amount of money to confuse the majority their customers and please a small segment?

My point is not to argue with your position that you would like to see MS make VFP the best development language on earth, my argument is with how realistic that wish is.

I'd like to win the Powerball lottery, but I am not betting my house on that wish. I think the time has come to stop the wishing, face the facts, and prepare for the future.

The future is component development where systems are built from parts developed with various different development tools and scripted to work together.