>What are you thoughts on a compile time choice? CLR or non-CLR(pure VFP). CLR applications would then be a subset of full VFP.

Waste of time and resources...

I'm with Ed. If you're gonna throw out the stuff that makes VFP unique you might as well code in VB or C#. For that matter the syntax won't be that different between these two either because you use objects extensively, so everything is

object.dosomething()


+++ Rick ---


>
>>I think you've missed the essential truth of what little we've seen of .NET; the biggest difference from my POV is in the process of subclassing CLR classes, which require a COM wrapper to be accessed from within VFP, and to subclass VFP COM classes, which require us to export the typelib to CLR to make the VFP COM object referencable and subclass-able using a CLR language.
>>
>>OTOH, are you at all aware of the costs of converting VFP to the CLR environment? No, probably not - you'd have to give up the native data handling, string speed, macro-expansion and a good deal more. If you want "backwards compatibility", you don't want to see VFP a full IL pcode engine, and if backwards compatibility is not an issue, then WTF is wrong with recoding in VB or C#, which are full players, and in .NET have inheritance?
>>
>>IOW, read the facts. If you think we're getting screwed, jump ship now; we're probably at least a year from a live release of .NET, at least a major OS release (oh, yeah, you need Whistler to play fully in .NET) and IAC, if those piss-poor clients still trying to squeeze out work from that 8MB 486 are unhappy with the system requirements today, they're in for a very rude shock.
>>
>>Download the PDC Tech Preview and play with what CLR actually does before speculating.
>>
>>.NET - Not Effective Today