>>>
>>>There was a time when it was proposed (here on the UT) that a data entry form be done in VFP and C# so developers would have an example of both to look at. It turned into a flame war though and arguments about the many ways to do it in both languages and so it never happened. Sad...
>>
>If Kevin G were allowed back, we might actually get that discussion (which was very informative) going again and get some done in both VFP and dotnet for comparison and learning...

One of the problems with these kinds of things is dealing with the number of ways everything can go together. For example, VFP data or SQL Server? From my experience, accessing VFP data in .NET is pretty clunky. It's just different enough to really complicate things. SQL Server is a much nicer experience. Then you've got the "thrown together"-type VFP form vs. a reasonably well designed form (usually involving a framework of some sort; either homegrown or otherwise). I kind of cringe thinking about showing people the thrown-together type form for fear of it suddenly becoming their preferred way to do everything (and cursing how much more "complicated" it is as compared to VFP).

If you suddenly want to see an ASP.NET application you've got the added complication of the differences between a desktop app and a web application. And the same issues with backend - VFP or SQL. I would guess a lot of VFP developers might actually want to see ASP.NET to VFP data, so they can expose their existing data on the web. But again, I've found that if you need VFP data on the web, some other VFP-specific framework is nicer to deal with (ex. Web Connect, FoxWeb, ActiveVFP, etc.) and usually a better choice.