Jim,

>>>So doesn't this also make the argument for a VFP.NET?
>>
>>
>>Hi Jim..
>>
>>I don't see how it does. If you are left with VB .Net and VB .Net already exists, why would it make sense to develop a redundant language? Also, it would appear that many VFP developers will give serious consideration to C#.
>
>Then why is there a C# and a VB.Net? Can't the same reasoning be applied to having a VFP.NET? Seems to me it can. Just as they are different from each other, having different adherents to each, so it is the case with VFP.

If I may toss out a possible answer.. My guess is that there are two products as a result of there traditionally being two products. <g> Not trying to be a smart mouth but I think that there's a better than even chance that at som epoint in some future product we'll see a melding of what are now multiple products. Personally, if the developers at Microsoft could come up with one product that had all if the functionality od all the various disparate current products I'd jump to it faster than a frog on a hot road.

This would be particularly interesting if you could reduce, through the compilation process, all code to the same functional level as ASM code. I don't think that this will happen soon but it would be a worthwhile goal I'd think. Small binaries, so often scorned these days, really are nice to have.

VFP is out of this process for the moment as a result of some of the unique functionalities of the language. Whether that is good or bad remains to be seen. Most think it was the best 'path' to take and I agree.

>
>>
>>VFP should stay right where it is. It is an investment that should continue to be leveraged and used in conjunction with VS .Net.
>
>Of course it should, and continue to grow in its traditional ways too. But I don't see how that precludes a VFP.NET.

I don't think it does. As long as VFP can participate that's all I care about.