Hi Mike,

I'd like to comment on the "differences..." portion of your document. You say:

"It has its own database engine. "
I can't argue that as a fact, but it does prompt me to ask 'what real good would VB or C++ or C# be if they *couldn't "do data"? Since these others can "do data" through additional components, doesn't this make them 'equivalent' once used to "do data"?
And in this case, wouldn't an integrated database engine be a beneficial feature of a product?

"It has techniques for accessing remote data that are unique to Visual FoxPro. "
Would it not be true that VB and C++ and C# also have their own unique techniques for accessing remote data? I believe so, in which case this is really not a "difference" between VFP and the (presently) included .NET programming languages.

"It does not use the common language runtime. "
That's a MS decision that could be "corrected". And if VFP is just about finished (as has been stated on UT at various times) then wouldn't that be one task that the VFP team could undertake?

"It will continue to make use of COM and COM+ to communicate with external objects instead of the new mechanisms available in VS.NET. "
Is this a problem... or even a difference - won't the others also continue to make use of COM/COM+? And again, if VFP is just about finished, wouldn't this be a task that the VFP team could undertake?

"It has its own set of design surfaces that differ from the rest of Visual Studio. "
I thought that DevCon showed them all getting ever-closer though. Maybe by VFP8 VB would be endowed with all of the capabilities it is now missing and they will be the same (IDE-wise).

"Visual FoxPro provides many features that are not supported by the common language runtime. "
Isn't this essentially the same as your third point above? And isn't the answer basically the same?

"Visual FoxPro 7.0 code will not run in the managed code environment and will most likely outperform VB and C# code written to perform the same functions."
Again, if VFP is just about finished, aren't there some 9+ months left to do something about this?

It's good that the Fox Team wants to know how we feel. It would also be nice to hear THEIR thoughts and assessment(s) (pros and cons).

Finally, virtually all of the businesses that I can think of NEED to "do data". And virtually all of the businesses that I can think of will NEED VS.NET for the 'foundation' of their business applications.
BUT... countless of the businesses in the world cannot afford the costs of full-blown SQL-SERVER/Oracle/DB2 nor the ancillary costs associated with them and nor do they need ultra security/scalability/etc that they might deliver.

Overall it looks to me that VFP must remain in VS.NET and that VFP must untimately be made to participate in as much of that platforms functionality as possible.

Regards,

JimN


>I posted a document to the wiki at http://fox.wikis.com/wc.dll?Wiki~ShouldVFPBeInVSDotNet~softwareEng regarding this subject. The Fox Team is really interested in what we think about this. Please feel free to add your comments and opinion.