Hi Colin,

eTecnologia is aiming at 100% compatibility. The resulting code compiles to .Net as an EXE or DLL. If you don't need .Net features, you won't have to learn any .Net, based on what eTecnologia has said.

That said, there are a lot of nice extra features one can use from .Net, and since VFP.Net is a first-class .Net citizen, it can use them directly. So what I do is go find an example of what I want and add it to my VFP program, using the .Net notation right in VFP. It's very cool.

Hank

>>Hi Boudewijn,
>>
>>I'm not really replying to you, but to those many messages in this thread with a common message of "this is all too late." I think there is room for varying opinions here, for various reasons. It is some of those various reasons I am going to list, in a hope to balance the scales of discussion.
>>
>>1) VFP is supported until Jan. 2010. If VFP.Net (my personal name for the eTecnologia effort) arrives by then (as Samuel has said, as of 2 months ago or less, that it would), then we will have a seamless transition in terms of developing with a supported product.
>>
>>2) None of the dynamic languages, to my knowledge, provide what VFP.Net gives in terms of a) building a CLI-compliant EXE; b) providing an easily extensible, in VFP code, IDE such as we have in VFP (but better); c) provide the full range of capabilities we have in debugging (think: use of the command window to test out alternatives, something I've done about 100 times at least in the last 2 days); d) provide VFP-style object subclassing of .Net controls. And a bunch of other things. In other words, VFP.Net is what a dynamic language should be in .Net, and more (they are adding a lot of additional features for a language which has been dormant for what, 4 years?).
>>
>>3) While it is possible to work without extensive metadata-driven and OOP framework support in VFP, that's not what I and many others have been doing for the last 7 years, at least. Match up plain VFP to .Net with training and experience in each, and it probably is something of a matchup. Match ours (and others) tools with what is available in .Net, and the story changes. .Net, partly due to its IDE, partly due to strong typing, partly due to the limitation of existing dynamic languages, does not give the power that VFP is capable of bringing to the software development table, and which VFP.Net is going to best. That's right: VFP.Net improves on VFP's development capabilities in numerous ways. Run a sql select through SQLEXEC and you will get back an updatable cursor. Wow! The cursor you get back is an object, and properties of that cursor can be bound with bindevent. Wow!
>>
>>4) VFP.Net will have the ability to design (and subclass) in what we think of as VFP forms, and have those forms compiled to WPF or Silverlight. Look at the threads on this topic here (in the .Net section) or other places, and you will read the laments of VFP developers, and the various suggested workarounds, along with the limitations these workarounds bring.
>>
>>I could go on. My perspective (and I realize it's one of many) is that I will be better served by VFP.Net than by either the strongly-typed languages or the current dynamic languages in .Net, in terms of my ability to deliver software applications that have the quality and speed of development that I currently have in VFP, combined with seamless access to .Net UI and infrastructure features. And what I build will be directly accessible through any other CLI-compliant .Net application, which will give me first-level membership in the .Net family.
>>
>>And yes, it has taken the 7-member team producing VFP.Net a while to create it. It is certainly not their only job. And for some things, they appear to have been waiting for .Net (and Mono: everything written in VFP.Net will run under Mono) to mature. I think it is worth the wait, and of course YMMV.
>>
>>Hank
>>
>>

>
>Hank down difficult do you think it will be for someone who has used VFP for years to make the transition to VFP.new - I have no .Net experience?