>So just use C# huh? I mean that's how I'm supposed to battle the lack of marketing by MS and misconceptions for VFP when it comes to dealing with my current and potential clients? Hey it doesn't bother me any - I mean by the time all this *functionality* is added into C# and VB.NET as you're implying, then there will be no more new VFP's anyway because it won't be needed.
>
>And how irrelevant is it? What you're suggesting is that it's easier to market this odd-ball step-child that's aparenlty outside of the big 'push' that MS has going than it is to simply make it part of it. Hey if you can't beat em, join em right?

Let's say there was a VFP.NET language added to VS. And let's say various VFP-like data features were added to VB and C#. Then what would happen is that IT shops and companies would ask "Should I use VB.NET, C#, or VFP.NET?" The answer would be "VB.NET and C# are more strategic and have more resources on their teams, and VB has the same exact functionality as VFP.NET since data stuff was also added to VB.NET.". Then all the samples out there would need to be in VB.NET, C#, and VFP.NET, all the same features added to VB.NET would have to be added to VFP.NET and it would take away from the overall features added - even when VB.NET had "all" of the same functionality as VB.NET. If there was a VFP.NET, it would not have one feature more than VB.NET. So why would someone want VFP.NET, what would be the benefit both technically and marketing wise?