>I don't know if that's a valid counter-argument, Ed. You are certainly correct that VB and VC++ developers better understand threads, processes, and the sticky little nuances of dig-deep Windows coding. So they make superior components. Yeah? So? These same "Masters of COM" will design tables with no primary keys; wouldn't know RI if it bit them in the butt.
>
>In fact, whats really telling, is that most VFP developers will profess to want to learn more about the nuances of Windows programming or the Web or other "to-the-metal" concepts, but a lot VB developers openly flaunt ignorance of databases and data design.
>

I'm not faulting VFP developers, especially not wrt file handling. VFP does a remarkable job, and I still write -lots- of VFP, and workarounds to let me do much or most of the app in VFP where the app is data-centric, but when it comes to other system-critical demands, "VFP don't play that game", or where we could pound our heads against the wall using VFP, but in many cases, another tool (who will remain nameless but it's Visual, and the second word starts with one of the first few letters of the alphabet) does what needs doingwith a lot less code and far fewer bruises on the forehead.

I write lots of VB and VC++ - at one point, far more production C code than VFP. Even then, I still relied on VFP where it was at its strongest - I did tons of data conversion for building data describing routing and rating services, and in most cases, VFP made sense. The engines which worked with the results were written in C++ - we needed strong linked list support, free-threading and a smaller code footprint, and disgustingly large matrices. The customers got a C++ based product - but without VFP, it would have been much tougher to deliver usable, standard data from proprietary data, generally processed using a proprietary process. VFP definitely was the right tool for this task; it would have likely crashed and burned for the routing component we created (although some parts were prototyped in VFP and then converted to C - the interpretive environment makes VFP a natural for investigating algorithms and code as you go sessions - do stuff in the command window until you get what you want, copy the code window and paste it in a .PRG, and trim, comment and enahnce at will...)

>Database concept speakers at VBITS get ragged on big time.
>

Big deal - I'd guess fewer than 15 people made it to my session on pointers in VFP. People voted with their feet. We see a ton of questions "I want an API call to do ..." but rarely a question on what goes on under the hood of VFP where it's talking to Windows. Lots of "I have this API call, translate it to VFP for me", never "What can VFP pass to a DLL?" or "What does DECLARE...DLL do?" To VFP programmers, Windows is the red-headed stepchild; if it isn't built into VFP, it's a bug, or it should be in the wishlist and listed as a bug until then.

>Now, consider the full lifecycle needs in systems development: What's more important in both knowledge and attitude?

I have a rather cynical view of VFP programmers; there are too many who use macro-expansion where name resolution is both faster and safer. I truly believe that in order to write good WinApps, you need to understand Windows. You can write a better WinApp if you understand what Windows can do for your app, and when it gets in your way.