Jim,
I agree with you and I think there's a lot to be said for combining the 2 technologies (VFP and .NET) to offer even better solutions than you might get with just one or the other. Examples are publishing and consuming web services between .Net and VFP and calling VFP mtdll COM Servers from ASP.NET. More than likely, like you said, there will be more than a few things that .NET can't do that VFP will be able to do.
>John,
>
>I agree with your position on this issue. However, I also am not reallly interested in seeing VFP go .NET as the features we would lose in this are not limited to macro expansion (ME). There is a lot more about fox that would need to be compromised.
>
>But for a fox developer to dismiss .NET is a very large mistake. I've been around long enough to remember the mainframe cobol programmers who said the pc was just a toy and would never amount to anything. Many of them found themselves out of work a short time after they said that.
>
>Even for the developer who intends to stay with VFP as their primary tool, it will become necessary for them to access .NET stuff from fox. When our clients find out that their systems can do this or that, they will demand that we supply the feature in the systems we build. The time to learn how to do this is NOT when the client asks, but rather before the client asks.
>
>Many of use remember the time when DOS was king and GUI's were toys. Some of us saw the promise of the GUI's and started to learn what we could about how they worked and how to work with them. A few short years later the GUI was king and there were a whole lot of developers who laughed at GUI who were struggling to catch up.
>
>.NET (or something like it) is the future. With the global network becoming more and more pervasive, something has to come around to tame it and make it easier to exploit. .NET promises to be that thing.
>
>Even if .NET should fail to catch the favor of the world at large, the things learned by studying it will be of value in whatever might take its place.