Hi Greg,

they already have dbf support, and have even extended it to > 2G files/records etc. It's really quite advanced at this stage. We have a community support group at Google Groups (google on Google Groups VFP .Net Compiler to find it) where a few of us put up examples. It's not very active: I think everyone is waiting, and that's the problem that Victor is indirectly reflecting, I think. If everyone waits to find out whether it works, where are they going to get the development money? When I bought the CLR Extender (which has already proven its worth in letting me get out a Google Talk VFP app using the xvmpp .net library), my thought was to support that development through my purchase.

There is some information on the next release on the community group; and when I get time to put up a YouTube on converting a VFP form application in the new IDE, I'll link it from there.

Hank

>>>Hello.
>>>
>>>I´ve been looking at VFP Compiler for NET. Realistically, you may expect to be at 95% VFP compatibily in a couple years. This way, you may end rewriting 10% of your code to update your current VFP projects to .NET instead of the .NET learning curve plus rewriting of projects. Still worthy the wait, specially if you have a big codebase with lots of customers. Also you may expect to extend your codebase in those 2 years to come without the fear of having to rewrite the entire thing in another language.
>>>
>>>
>>>I've been thinking in ways to finance the entire thing, maybe evangelizing it more, looking for seed capital, angel investors, and so on. The more money is in etecnologia, the faster and better the results. Any coment?
>>>
>>
>>I don't know much of anything about Etecnologia, so take this with a grain of salt, but I seriously question that estimate of only having to rewrite 10% of an existing VFP app. MSIL code generated by Etecnologia will have to comply with the Common Language Specification (CLS) and that is dramatically different from VFP. Data types are different, arrays are different (1 based instead of 0 based), all the VFP data handling commands are out the window, etc. etc. etc. Maybe Etechnologia is going to include some type of code converter to make VFP code compliant in an automated way, I don't know. It just seems like a pipe dream to think it will be possible to deploy a VFP-flavored .NET application without understanding .NET. And that's the hard part of the learning curve.
>_________
>Mike,
>
>I believe it can be done without having to rewrite any part at all
>
>The easy part is the language (using something like yacc). As to the type checking, that's easy as well. Since it's vfp you're converting you can only do runtime type checking
>
>You can define a class - or a struct with an enum of type
>Something like
>

>class vfpvariable // maybe also for constants and intermediate results
>{
>        enum type; // eg 0=int, 1=double, 2=string, 3 = logical, 4 = object, ....
>        int  valueInt;
>       double valuedouble ;
>       decimal valuecurrency;
>       string valuestring;
>       bool ?  valuebool;
>       object valueobject ;
>}
>

>Since it's a class/struct you can define operators. So the code can easily be translated into c#
>The only problem - since it's runtime type checking - is that most of the time will be spent on checking the types and converting from one type to another, eg int >> double, double >> currency. Hey - but who cares - as long as it runs
>
>That is the easy part
>
>Then there are the vfp controls [ form, checkbox, ... ]
>
>Finally, there's the dbf access - which is imo the difficult part
>
>Code can be emitted and JIT compiled