I think they always put VFP behind, I really like VFP and have used for the last 7 years, I'm up to the point were I'm going to start learning C# or something else, because I don't like to be left behind, It's always harder for VFP developers to do stuff that VB has been able to do for along time.
Anyway I read in a INFOWORLD article that VFP was going to be part of the CRL, seems like it won't, (that is bad) anyway if they do a lot of XML and other stuff that will be very usefull and hopefully that will make as more productive.

Fabian.

>Jess,
>
>>Ohhh... it seems they're passing the burden to us. Why the need for a dialog first? Are they not sure yet of the impact of CLR and .NET technology?
>
>Correct. No one knows yet just how the whole .NET thing is going to play out, and how the performance issues will be addressed. But, when you see all the new stuff in VFP7 related to XML, SOAP, Web Services, Database Events, and so forth, you can see that there are very major changes already done -- and that takes resources.
>
>>And why it is only an option in VFP8, is it not a necessity? They were the ones knowing the technology in advance, isn't it?
>
>The dialog is needed with the community to look at creative ways to port VFP to CLR if the community thinks it is necessary, considering the data-manipulation language commands that would have to be mapped over to ADO+. Think about it: how would you handle converting the VFP data commands into the common runtime, which has ADO+ as its mechanism?
>
>>But on the other side, you can't build .NET enabled application in VFP foundation without CLR.
>
>Not entirely true, Jess. Once you have the .NET framework installed, you can call into it from even VFP6:
>
>oSQL = CREATEOBJECT("system.data.sql.sqlcommand")
>oADOCommand = CREATEOBJECT("system.data.ado.adocommand")
>
>and VFP components can be called via the Interop layer. VFP Web Services can be consumed by .NET applications, and more.....
>
>It's not as bleak as you might assume.