John, thanks for the comments. I guess what I'm saying is that there's probably plenty of room to combine the technologies, especially in the short-term. For example, we can create an ASP or ASP.NET web component today that can take advantage of VFP specific strengths(string processing, DBF speed, portability) and sell it to the general public. The fact that it is VFP is giving us a distinct advantage over other web components created with VB and VC++. As a matter of fact, many of the new features in .NET for web apps that I've seen are things you can do in VFP today. An example would be HTML template processing...
>Hi Claude..
>
>It is important to note that Web Services is not a .Net thing. VFP is good at publishing and consuming web services. There is no question that a lot of VFP code is going to run, and probably should run for quite some time to come. At the same time, new features/apps will need to be created that will need to leverage those services. Web services will bridge that gap between VFP and .Net.
>
>As for the possibility of a VFP .Net, in some ways, you could argue that it is already here, in the form of VB .Net. I have long said that if you take the data-specific parts from the VFP language, you are left with VB. As far as C# is concerned, I have no doubt that many VFP developers will eventually go toward that realm.