>I'd like to understand your point of view, but from what I can see, moving VFP into the .NET world would be sudden death for the product, as opposed to the current situation where it has its own team and its own community that knows VFP can handle anything thrown in its direction.
>
>So I guess my question is, what would VFP developers and end users of VFP applications benefit by VFP becoming apart of the .NET Framework (CLR, VS.NET, ect.)

Hi Mike,

After looking at the differences between FoxPro and other languages, as shown on MSDN, I now think there is some real value in porting VFP's language elements to the CLR (of course, the data engine is out of the question). It would be somewhat similar to VB, but I think there are enough differences in syntax and functionality that VFP developers would welcome the support.

That being said, I have to agree that this would be the death of the product. Technically, there is no reason that the VFP product and CLR support could not be handled simultaneously, but politically speaking, it could not be a success. Developers would either reject the CLR support, or bosses would force projects to be ported over, assuming it would be easy. I fully expect this to be part of the migration strategy, if/when the VFP product cycle ends. Until then, I think we can do without.

If that day comes, I will definitely miss native cursors. I wonder if VB developers use ADO recordsets to data-drive applications? It doesn't seem as appealing under those circumstances.