>I agree that it's not worth thinking of a switch. For me it's really a matter of having more than one tool in the arsenal. I've always been playing with VB since version 3 but only until recent months am taking the time to learn it for real. And doing some work on it too.
>

There are things that can't be done in VFP, but can in VB. VB syntax and understanding of it crosses product boundaries in its applicability, particularly scripting and Office product automation. If you have a real need for ActiveX UI objects, no contest - VB offers more, because its UI behaves as the Windows UI model expects it should; each control has an hWnd, and it's easy to sink and signal new events in the UI. And the odds of finding useful samples in the standard docs in VB is much greater than finding the same examples for VFP, so if you have trouble translating between VB and VFP syntax, you stand a statisticly better chance of finding a useful sample in standard docs for a product.

There are things that are awkward at best in VB, but a piece of cake to do with VFP. If data-centric apps are your primary target, VFP is likely to give you a leg up on what a VB developer would need to do to match the functionality with VB. There are alternatives to VFP for data-centric applications, and AFAIC, better tools for most situations where VB would be preferable to VFP, like C++ or Java of some flavor, but that's more a matter of language comfort in the first case, and a preference for a stronger OO language in the second. I'm far more proficient in C++ than VB, and far less experienced in using Java, although I've played with it and like the underlying philosophy. I just can't see enough reason to switch to Java rather than C++ when I know C and C++ fairly well.

AFA what pays best, being able to come up with solid solutions without an undue attachment to making one tool fit a problem seems to be what people want to pay me to do.