One addition to what Steve said about VFP.Net not interpreting: it does have a Command Window from which commands can be executed, both in development and debugging. On their worklist is extending that to having the ability to write code snippets (multi-line) directly in the Command Window and execute them.

Now if they'd only finish the thing. <s>

Hank

>>Mike,
>>
>>Thanks for the question.
>>
>>You are correct. The vfp.net compiler isn't an interpreter. In other words it does not take your VFP code and turn it into VB.Net code. Instead it compiles it into the same intermediate code (IL) to which all the other compilers compile. You will probably say, "Ok, so how will a .Net guy maintain an app written in VFP if they don't know VFP?" My answer is that based on my experience with an integrated team of .Net guys and Fox guys the .Net guys have no trouble reading VFP code once they understand a little bit about it. The learning curve is orders of magnitude less from .Net to VFP than it is from VFP to .Net.
>>
>>Having said that, you can mix and match VB code with your VFP code without any problem. You could even write in VB and use only the data layer so that you could access DBF's using VFP syntax. You could also take a VFP app and add functionality to it and write that functionality completely in VB. It's a really awesome technology that is extremely flexible. I wrote a little test app for a demonstration to management in my company that showed how you can get your VFP code to run 300%-1000% faster just by declaring all your LOCALs using the TLOCAL compiler statement and strongly typing your LOCALs! The same easy optimization can be used with the LPARAMETER statement (TPARAMETER). If anyone wantws to know why this work this way post a question and I or some other beta tester can explain. You can also find hidden bugs that way if you have a variable that accidently changes type.
>>
>
>That's really interesting about the performance boost from TLOCAL and TPARAMETER.