>>>>>There is a difference between creating entirely new applications or maintaining existing one. New applications are rarely created in VFP anymore. Most happen when the client isn't more specific than "must run on Windows XP" and the developer is a VFP developer who is quicker at creating the app in VFP than in .NET (or whatever). If I'm asked to develop a new application I usually propose .NET and then use .NET, or VFP, or whatever the client wants me to use.
>>>>>
>>>>>For existing applications it's much easier. If the application is written in VFP this is a huge investment that you cannot easily throw away for the sake of using a different technology. Most clients quickly understand this point when you express it in hard currency and time to market. For existing VFP applications my suggestion is usually to keep it in VFP and extend in .NET. New features that can be written in .NET, should be written in .NET, but it's nonsense to migrate for the sake of migration. My clients take different steps right now. Some are doing their third attempt of creating a new application, this time in .NET. Others keep using VFP and just extending with .NET. Others are using VFP only. Others are only doing .NET. Some are abandoning Microsoft and switch to Linux and open source.
>>>>>
>>>>>It often depends on the scope of the software. With application that are designed for a single client it's often no problem using VFP. The environment is under control of the company making it easier to accommodate for the application. For vertical market applications I definitely see a switch away from VFP now. .NET compatible computers do have the critical mass to make deployment possible without running into lots of issues. During the first five years this was a major issue not to go to .NET.
>>>>
>>>>Thanks for that - unfortunately in the example I gave you and one other I have come across there is a growing tendency by non VFP developers to rubbish existing VFP applications on the grounds that as no one uses VFP any more it would be better for them to rebuild the application in whatever language they happen to use - very often SQL server where they conveniently forget that they then have to add on the visual front end
>>>>
>>>>Depressing when for a single Client application within a single office VFP is still the most powerful tool I have come across and its visual interface programming capability is second to none
>>>>
>>>>The ultimate measure of an existing application surely must be whether it does well what it was designed to do
>>>
>>>One option I hope they are considering is migrating data from DBFs (which it sounds like the data is in) to SQL Server without pitching everything else. There are a lot of good reasons to get away from DBFs. As Christof says, though, the cost and time of a conversion project are going to be considered by management as well. I agree with him completely that it's silly to completely rewrite a working app just to be on the flavor of the day.
>>>
>>>New development (as opposed to enhancements to an existing one) is a different story. Anyone would have to be a little nuts to do that any more. I don't hear about much if any of that. All my VFP work the past several years has been maintenance work.
>>
>>Yes I agree - change the back end keep the front end if you want to upgrade a vfp application - why is it though vfp has such a bad name for new apps when there are many instances where vfp woulf be a great solution for small companies - rapid development time etc - so you think the vfp community are partly responsible for this?
>
>I think much of the VFP community has been incredibly loyal. It's just perceived as a dead product in the corporate world. Not sure why that is.

Mu client said nobody uses VFP any more - how many users worldwide do you think there are? - perhaps it'd dead because Microsoft say so