Oh, so now Samuel is going to not only keep VFP alive after the vendor has kicked it to the curb but actually extend it? Single handedly? Now I've heard everything ;-)

>Hi Mike,
>
>have you read the eTecnologia announcements of features in the various releases? There have been evolutionary changes to the VFP language announced with nearly every release, I think. And Samuel has announced publicly that there will be more (some of which I have noted in various posts). So I'm not sure what deadend means here: this is a living, growing language. How is it a deadend?
>
>Hank
>
>>>>Why target only VFP developers? Who else would want a VFP compiler at this point? Do you think new people are coming to the language? -- looking around at the available options and saying, "Yup, that's the one for me!" That hardly seems likely.
>>>>
>>>>I get what you are saying about the strengths of FoxPro. As you say, there are DOS apps still running and working. But why would those people want a .NET compiler?
>>>
>>>I have a client for whom I maintain a DataFlex application. (Anyone remember DataFlex?) I would like to convince them to rewrite the app using a large FoxPro application that I own as a base. I'm worried about the question:
>>>
>>>Why would we move from one deadend language to another deadend language?
>>>
>>>A VFP.NET would remove that worry.
>>>
>>
>>It would? Maybe there is something fundamental I am missing about eTecnologia's product. I thought it was a tool to compile VFP code to .NET. (Is that incorrect?) I don't see how that makes VFP any less deadend.