>>>A VFP .Net would simply be VB .Net.
>>I Agree but why not move VFP towards being CLR compliant.
>
>If you accept that VFP.NET woudl be VB.NET, doesn't that answer your question? Why would you spend the resources to move VFP to be CLR compliant if you gain nothing in the process (assuming that it will come out like VB.NET... and it will) plus alienate every VFP developer that does not want .NET?

Hi Mike,

I think you missed my point. It's a mute discussion anyway since the decision has already been made. As a developer I felt the one thing that is sorely missing from .NET is a data centric language such as dbase. Also, that I could see no “technical” reason why the VFP runtimes (including the database engine and language interpreter) could not be ported to interface to the OS via the CLR and still maintain ALL of its functionality. You might want to ponder the benefits to VFP if it could run as VFP does today and have the ability for it’s classes to be used in any VS.NET application directly or vice versus.

Yes I can perform analytical data processing using the existing .NET languages, and write hundreds of lines of code. With a data centric language the task becomes much less daunting. It seems that the .NET languages and the framework’s System.Data classes are great at reading, writing, updating, filtering and presenting data. That’s where the designers dropped the ball. I guess they figured nobody does anything with data any more other than that.