>>
>>Kevin, just give it up... Leave it alone.... Your motives are clear...
>
>His motives are based on reality and concern for the customer, not just a developers' tool preference.
>
>I think the world of VFP and I much prefer it to any strictly windows development tool.
>
>That said, VFPs future is sealed. Any windows development project I do now starts with the premise that I can probably do it in VFP faster than other tools, but I can not guarantee fitness for service past Vista, and I will not make any claims of web capability in the future (which more and more companies want to migrate to). I make sure the customer knows this very clearly up front.
>
>My recommendataion now is that for any major new development, VFP is not the tool.

Question is; what IS the tool to replace VFP?

If you have new project with lifecycle
expectancy spanning more then 20 years, then yes we do need to get look at another tool, but I wld not jump a rope and drop VFP any time soon.

There is safety buffer period of I wld say minimum 5 years to get prepared
for a transition, and within those 5-7 years meny things can happen.
NET might get better/cheaper do develop, or some other tool/platform might emerge.

I would not do ANYTHING right now, based on NET-hype & VFP-EOL anouncement momentum, but when time is right and I can foresee precisely how to do it and where this transitions are going to lead me. This especially applies
to people who hv big dependancies in terms of responsability for maintaining solutions deployed already to customers/businesses.
Student can choose NET any day, but that is not our case I wld say.

So my reccomendation would be to keep eyes open, evaluate as meny other tools as possible, and then eventually wisely choose what is best for everybody. As we had instinct to embrace VFP, we will know right tool for us moment it arrives :)

my.2c