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

So that's why you know your Windows API pretty 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.

You're right. I suppose I'm in the "corporate developer" mentality when I say having more than one tool. Guess I'm thinking on my employable qualities there. I do get my job done though. Most of the time anyway :)