> Yeah I know there are significant technical issues in doing something
> like that - as matter of fact I assume it's basicly a rewrite of foxpro.

Victor,

this assumption is actually incorrect. This wouldn't just be a complete re-write of VFP, it would also mean that the language had to be re-designed!

How would you like a FoxPro where the following statement is invaliid:

oForm = CreateObject("Form")

Or how about not being able to do this:

LOCAL lcCustomerName
lcCustomerName = Customer.Name

Or how about the following code in a form's Init event not working:

FUNCTION Init()
THISFORM.txtName.BackColor = Rgb(255,0,0)
ENDFUNC

Or how about this type of approach that would be entirely invalid in any .NET language:

FUNCTION Something(oObject AS Object)
oObject.Execute()
ENDFUNC

NONE of this would be valid in .NET. The VFP language had to be changed entirely. Here are theoretical problems to what the new language could be like:

LOCAL oForm as Form
oForm = new Form

And:

LOCAL lcCustomerName as String
lcCustomerName = Customer->Name

And:

PUBLIC FUNCTION Init()
LOCAL oForm as MyForm
oForm = (MyForm)THISFORM
oForm.txtName.BackColor = Color.Red
ENDFUNC

And there is no equivalent for executing a method on any object that is passed.

So as you can see, things would be quite a bit different. The language would be almost identical to VB. None of your existing code would convert over any easier than it does convert to VB.NET.

And asides from these language problems, there are logical problems. How much sense does it make in .NET to open a DBF? How much sense does it make to open a DBF when you can not bind to its data? How much sense does it make not to have any of FP's query and data manipulation language?

And then of course, there are a number of concepts in VFP that plain would not be supported in .NET. The ability to create forms (SCX) rather than classes. The ability to add a button to a form and add text to it's click method, rather than a click method on the form that is linked to the button.

I could go on and on. In fact I have written a quite lengthy explanation over a year ago on the fox wiki. Long story short: Unless we'd turn the language into what's almost identical to VB.NET, and unless we were willing to get rid of the features that make VFP great, there is no way to pull this off. Trust me on this. I've spent quite some time investigating the details...

Markus