HI Kim,

>>Accorinding to my information, Only C#, and VB are fully based on CLR, C++ has the possibility to compile to CLR, but you aren't forced to. I don't know where you've got the info of COBOL, but this seems highly unlikely to happen in any case.
>Cobol support for CLR see the following URL.
>http://www.microsoft.com/PressPass/press/2000/Jul00/PDCGroundswellPR.asp

There is not a word about compiling to the CLR, it only states that the languages will be able to take advantage of the .NET framework. This is also the case with VFP. VFP can take advantage of the .NET framework, but only can't compile to the CLR. The advantages and disadvantages of this are (at least to me) unclear.

>>If VFP follows the CLR field we probably should give up much of VFP features like the native database engine, the DML, runtime compiling, EVAL() and macro's. IOW it would be whole different language. If we need something like this, why don't switch for VB or C# ? VFP has strenghts that probably cannot be implemented in the CLR. Therefore I vote for not getting into CLR.

>I am of the opinion that the language would lose some features but definately would not lose all its key features. For years, in the Xbase community there is always the argument that you cannot compile to native Executable if you want Macro subsitution support. This is not true. Please refer to http://www.alaska-software.com/e/products/xbpp/xbpp.html

This is simply not true. Native compiled languages cannot evaluate strings as commands (because they have to be compiled first). Either the compiler is included in the Executable or provided by a runtime DLL (Like in Clipper and FOX2.x) or the Executable does not support macro substitution and/or runtime compiling (Like C,C++ and others).

>IMOH, the talk about losing this and that feature is just FUD to keep VFP from advancing and finally given an opportunity for MS to kill it because it just do not have enough developer working on the product since is a backward product.

I think we have, different viewpoints on this one. Personally I think that if VFP walks the CLR path, it becomes so simular to VB, it gives MS more reasons to kill VFP than otherwise. Differences might be the strongest argument to keep it alive...

>Remember that for VFP to support COM it has to lose some features and I think we should work along those lines instead of just saying no to changes.

I'm not aware that with the support of COM (VFP 3 or VFP 5) we did lose any features at all. Can you point out what you mean by that ?

Walter,