Hi John,
>
>As far as your comments about VFP being in an "enviable" position, I cannot agree with that statement. I'll leave it to you to ask if you want me to expand on why I feel this way. As always, be careful of what you ask for!< bg >

Perhaps it's simply perception, but it would that since VFP can "play" in a number of different roles that has me feeling this way. Then again, maybe I've been over-energized by Ken taking on his position.:-)

Seriously, I would welcome any comments you would care to make. I wouldn't have posted to you if I didn't feel that way. I'm a rank "newbie" (haven't done much more than glance at the first VS.NET beta) so any infromation you provide is sure to be instructive. Just be gentle.< bg >


>VS .NET does not solve the limitations that are inherent in browser-based interfaces. VS .NET does however make it easier to create them. Still, one has to be mindful of the differences between IE, Netscape, etc.
>
>I don't see the relevant question being whether an application should be ported to a browser-based environment. Rather, I see the question of whether the Internet should be used as the network. I see VS .NET and Windows Forms in particular solving many of the distribution problems we currently face. Remember, if you use .NET controls/components as opposed to ActiveX, there are no registry entries to make! The windows common controls that were exposed as ActiveX controls in VS 6 are contained within the .NET framework.

This I did not know (meaning the common controls being exposed).

>I believe that portions of application functionality are good candidates for browser-based functionaity. For example, an ASP .NET page that allows a traveling business person to enter expense reports. Heads-down data entry interfaces or those were the requirements call for something that needs more control than a browser-based interface provides can easily be solved via windows forms. To carry it further, if I expose my business services as web services, then I can serve data up to mobile devices, ASP .NET, windows forms, VFP, VB 6, etc. In VS .NET, I can create all the user interfaces in one environment as well as middle-tier components, web services (natively), etc.

Oh I absolutely agree on this point.

>Through all of this, a specific language - whether you use C# or VB is totally secondary and quite frankley, irrelevant. To let the language drive a decision is to completely miss the point.

Are you saying here that there are no situations where a portion of an application might better be written in C# vs. VB and vice versa? If so, I find that quite an interesting point.