Michael,

>>No problemo... It's been something of a hot/sore topic with many for a few months around here.. <g>
>
>I gathered as much. Should have "Set Asbestos On" first <g>. I guess I should have qualified the post by saying “No, I don’t mean turn VFP to VB.NET”. Oh well, since I’m sitting here with a 101.6 temperature I can claim delirium.

<g>

Well, I kind of figured that out..

>
>>I believe that macro expansion functionality, the local memory management that the data engine des to gain the speed advantages historically associated with VFP and other issues are, from what I understand, a largish portion. Essentially, if you remove these features VFP ceases to be VFP and you might as well use VB.
>
>Ah, a few technical tidbits that seem reasonable. Assuming the language interpreter is ported there should be no loss of language functionality such as macro expansion. Speed is another issue altogether. To port VFP over to a CLR compliant runtime without changing the CLR itself would be a major task. Obviously the CLR’s memory management and System.IO classes would have to be highly optimized. To me it still seems to be more of a resource issue than a technical one or as Erik mentioned a "clash of philosophies".

Dunno Michael. From what folks say who apparently are in a position to know there's much more than "a few technical tidbits". Not to make light of your point mind you but I think it was determined that to make VFP a .NET compliant product meant essentially removing/changing enough to essentially make it non-VFP. That and the notion of now having to maintain two separate sets of code I'd think.

>
>After spending many hours learning .NET since the first Beta-1, I’ve grown to the point that I hate to go back to the old VS to use any of the development tools (Except VFP of course). There is simply no comparison. It’s like asking a seasoned VFP developer to go back to FPW. What’s missing in the VS.NET package is the data processing power of VFP. The more I use the System.Data classes the less dependant I become on VFP for data processing needs. It just seems a shame to have to write all that code in C# or VB.NET that can be done with only a few lines of VFP code.

I look forward to having the luxury of the time to learn. I'm far to busy right now to even think about this..