>Well, at least not if it never needs to be changed....
>
>If you need to change it you change it using eT (or Guineu) scripts/design interfaces and then compile it to native code or IL that includes any technology advances that have occurred in the meantime. Still the result has no residual connection to VFP.
>
>I say "scripts/design interfaces" because both Guineu and eT are extending the language to introduce new technology options. As you don't need VFP installed on your PC any more I can't see any need to regard the improved scripts/forms as VFP once they're imported into eT's design studio- just as a dBase prg would not still be considered dBase after you carry it over to FP.
>
>Yes I'm playing Devil's Advocate ;-) and the above isn't entirely valid, but let's cast a positive light, right? ;-)
>
>FWIW we've experimented with importing VFP projects into eT and ran into difficulties with encryption using a fll and/or DECLARE DLL statements. Obviously you can't use flls once you import into eT (since it's not VFP any more) and DECLARE DLL is a 32-bit construct that needs to be replaced with something managed. Right now I'm wondering why it's not possible to write a blowfish manager in VFP and compile it to binary x86/x64 using eT. Hmm. Could this be a new extension and my contribution to the effort? ;-)

Sure, why not? I doubt they would turn it down as long as it works.

By Hank's statement(s) they aren't all the way there yet with compatibility. Maybe some things in VFP just can't be converted to .NET, no way, no how. If they can get close I suspect that will be good enough for most developers who are interested in a product like this.