I understand what you're saying. .NET will compete with VFP at every level really: desktop, client/server, web, etc. The key will be our ability to show VFP's strengths when used together with .NET or totally separately. For example, we're working on getting some good examples for using VFP COM MTDLLs with ASP.Net. It would be nice if we could use this forum (VFP and .NET), maybe with Ken Levy's help, to point out the strengths of using VFP compared and combined with .NET...
>Also the article is talking about VFP 7
>What I was trying to point out is that the article is trying to put VFP7 as a client-server development tool and this for me is a shoot in the foot of VFP.
>My main development is COM+ application I personly dont like to do windows forms so much litle things that we have to consider the grid that dosn't behave like we espected etc... I prefer to do business objects where I don't have to mind with all these minor stuff.
>
>>>Then read the article and then whe will talk.
>>>
>>>>-snip-
>>>>>I'm saying that since the person that have written this article Jenny Brown as a statement that I pass to quote "What's VFP's role in this changing development world?
>>>>>While .NET is geared primarily for distributed, Web-based applications, VFP will continue to be geared toward robust client-server applications."
>>>>-snip-
>>>>
>>>>While I haven't read the complete article (to see its context), it is kind of an oversight, given that when VFP6 came out it was positioned as a tool for middle-tier components on an n-tier system. Let's not even talk about VFP7 and web services.
>>
>>Just FYI, I was agreeing with you. sheesh..