>
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.
>

Agreed. In all material respects - VB .Net is VFP sans the data specific parts of the language..


>
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.
>

Very true...


>
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.
>

I think some of this (fox dipping into .Net) will remain to be seen. Calling .Net components could be an expensive proposition, unless of course, it is done through web services. I see the reverse as being more likely for the VFP developer who makes the shift: using .Net to invoke VFP components that have been exposed through web services. If there is no financially/technically compelling reason to re-write them, the components should stay where they are - in VFP...