>>With that lack of marketing VFP's days are counted. No doubt about it.
>
>I disagree. That's why I replied to Thomas. Marketing VFP will not extend it's longevity. Here's the skinny:
>
>VFP is built on the Windows32 API
>The .NET Framework is a class library that runs on the API so applications don't have to
>Someday, the .NET Framework will be the native Windows platform and the Win32 API will run on that as an emulated environment
>
>Now, knowing that, how can Microsoft market a solution that they don't intend on supporting as a primary platform for years to come?
>
>The platform is just one part of it. Look at VB.NET and look at VFP. Which is easier for a new developer to learn? VB.NET by a long shot. Does that mean that VB.NET leads to better applications? No. It does mean that when faced with choosing a solution, unless you're already a VFP expert or have access to one, VB.NET makes more sense to the potential customer.
>
>Why would Microsoft market VFP to people (who won't be able to leverage the tool like the existing customers do) when VB.NET would be the more profitable solution for Microsoft anyways?
>
>As a developer, you have to look at VFP with no bias: Once mastered, it is an excellent tool for creating database applications. If your needs are to create those apps, you should be set. If your needs rely on how visible the product is, wouldn't it be alot more productive to move to the visible products than to try and increase VFP's visibility?
>
>I should address your point about being grateful to MS for continuing VFP while VB.NET grows. I agree, and you could go one step further to say Microsoft is moving VFP in the direction of VB.NET. With a new event and exception handling strategies, VFP8 apps may look surprisingly similar to the archeticure of a VB.NET app. So yes, its obvious that Microsoft is doing this for two reasons:
>
>1. One is that you as a developer are familiar with the most modern techniques available, making migration to the newest products easier
>2. One is that you as a customer are moving away from VFP to the news products
>
>With all that out of the way, here's the reality of the situaiton:
>
>1. The Win32 API will be supported natively for probably five more years.
>2. VB.NET is not "there" yet.
>
>There are two phases to .NET, as far as I can tell. The first phase is building the platform. This involves popularizing C#, building reusable components and web services; application frameworks and add-on tools. This is what's currently happening and why C# is getting all the attention. (I don't know how many VB developers you know but I was sitting at a table with 8 or 9 VB MVPs a couple months ago and every single one of them was claiming that VB.NET doesn't get marketed enough.)
>
>The second phase is once .NET is prime for application development, VB.NET will take center stage and (theoritically) take RAD to a new level. This is years off, if they can even make it happen (which is debateable, given this is the real hard part in the whole .NET strategy).
>
>So what's the deal? There are years left of great development in VFP. I'd be pleased if FoxPro was marketed more. But I understand that if it is, or if it isn't, I have development tool that I can do great things with. The killers are on their way, but they'll be a while. In ancy case I don't think marketing will solve anything at this point. You have to, as a developer, understand that there should be a gentlemen's agreement between VFP users and Microsoft. The way I've come to understand it is:
>
>Keep VFP backwards compatible, keep it stable, keep it powerful, keep it clean and elegant*, and give me what I want in terms of functionality.
>
>If that is not what you want from a development tool, then VFP is not for you. If Microsoft tried to market VFP to the masses, they'd have two VB's., which would be counter productive. But if Microsoft can market one product to the masses, and another to the people that know their job and know how to get it done, then they cover a wider area, and that is a good thing. JMO.
>
>*(compare the command window/project manager/and standard toolbar trio to the VS.NET IDE for a moment)

Very interesting reply. That seems to confirm what I think. We have to get real quick on the .Net bandwagon (I could've said train but it does'nt seem to be that yet).

I have a weird feeling because .Net does'nt seem like something absolutely necessary. It's just the new thing proposed (or forced) to use by MS. We can't take chances so we have to use it good or not because we know that others are going to propose it to their customers and we have to be ready when our customers will ask for it.

And with all the marketing and stuff it won't be long before the customers ask for it. So it's another endless loop starting. We have to use it because it's the new development standard and it'll become popular because we use it.

That is until they find something else to start another one of those loops. Which at that time will kill the precedent loop.