>I don't think it'll come as a surprise to anyone that I fully agree with everything you've said here. While in a perfect world, it'd be nice if VFP could be in the CLR arena without losing any of its current functionality, the world isn't perfect. If I need an application that needs to run under the CLR, I'll write it in VB.NET or C#. If I need to munge data under Win32, I'll write it in VFP.
>

>>I've said this before, but it bears repeating. Making VFP a CLR language makes it nothing more than a bad version of VB.NET and most certainly would kill the product.<<

What makes you say that?

Along the same lines we could think of VB.Net as a bad version of C#, (I think longtime VB people are already saying that) but that does not necessarily mean that VB.Net will die. I think VB.Net was created to accomodate VB programmers and bring them to the "latest and greatest" MS technology, and the same would be true if there was to be a .Net version of VFP. If you think about it, part of the appeal of the VFP Toolkit for .Net is the familiarity with the syntax, "feeling right at home" if you will.

I'm not saying that VFP should be a .Net language just yet, (perhaps the transition would be more transparent to VFP folks already accostumed to OOP) I just don't think that VFP will die if it was made into a .Net language.

Just my opinion,