>> 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

If everything would look just like VB.NET, what's up with C# and C++ and Delphi -- none of which are exactly like VB.NET.
Seems like .NET itself could be expanded to handle FP's query and data manipulation language. I mean why not if it's supposed to be so much better?
Quite frankly I'm willing to deal with the language changes if the end result is the ability to use the .net framework stuff. Plus you have to wonder how good a framework .NET is if it requires a complete language redesign to use it...
I still haven't quite got a handle on how it was determined that 'most' vfp developers didn't want this to happen because based on what I've gathered 'most' vfp developers seem to think that MS made a major blunder by excluding VFP from .NET.