>> The possibility of a VFP .Net has been discussed in many threads here on the >UT.
>Most of discussions was started by us or as our responce to Michel Fournier like in new thread ".Net framework" with "Requesting feedback from the migration"

This discussion has been going on for over a year.


>> I'll let Ken give you a more official response, but IMO, VFP .Net would not >be good.
>Thank you in advance, but you know already my opinion about VFP.Net.
>
>>It would pretty much look like VB .Net and you wouldn't gain anything from it.
>First - If customers like this design what can we do? We must satisfy them. We develop multilanguage technology for POS Oil Station Application - all lables, wait windows and messages we put in additional lbl_tables, same as .sct. In August firm, which we outsource ask us all toolbars to be change in coolbars. VB control, because of multilanguage technology didn't work. We are forced to develop new Coolbar control.

>The second - the technology go to web based applications. If we like to use all good technologies of FoxPro in web we need VFP.NET


Although they may not satisfy your customers, there are several ways to web-enable VFP including West-wind at www.west-wind.com.

Ultimately though it sounds like you would be better off learning VB.NET or C## and moving your development there than spending time here begging for VFP.NET. VFP will not move to .NET in the next version.


>My opinion is that VFP will move to database tools with wich we can easy develop n-tier applications. Most of his addvatages will be in the middle tier.
>Now we try to create XML/XSL converter with which developed with VFP pages very easy will be converted in that format.