>If the non .NET version of VFP would be so much more capable/powerful that a VFP.NET, do you think people would stop using the non .NET version of VFP?

I don't know about that, but... If a .Net user lands a project that is not really a .Net product they have something in their toolset that will still accomplish the goal. However, the VFP that "could" be in .Net and the stand-alone version would be two different things and there would still be a learning curve involved there.

I don't really view this as much different than switching from VB, C++ or C# to VFP. Look at the examples we look at today... how many of us find it very easy to translate other languages to VFP? I certainly do (with the exception of those low level, non-object based, C examples).

The key is that VFP.Net and VFP would be two different products and what would make VFP.Net better than using C#? Because we know the language syntax? Language syntax is the easy part of programming, IMHO. So, if C# (or some other .net language) is good for .Net and VFP is good for non .net or hybrid systems why not have two different tools?

Toni-
[F1 Technologies]