Gerry,

>The knowledge base (in all forms) for C/C++ is so hugh compared to C#/VB.NET, I think that any company that attempts to develop a new product in C# would be at a tremendous disadvantage relative to one using C/C++.

We use to say here in Brazil that's "nothing better than a day after the other with a night between then to clear up the mind" (sorry if the translation lost the proverb's meaning), but what I wanted to say you is that the sentence above kept hammering my head (as a background task) since I read it. This morning I realized what you meant, and I'll do my best to expolain you, as to the many other that helped me in this thread, what I understood from that.

I was saying that I should start learning some other low level language and add it to my box to improve my skills. Now I see that I may be wrong.

Also Daniel Rouleau wrote (Message #546405) "In my opinion, the VFP programmers that really know C/C++ are programmers that have done much more than database programming..."

The point is, perhaps I really DON'T need to incorporate or MUST ADD some of those tools to my arsenal. What led me to that conclusion that I MUST HAD was:

1. People (here and elsewhere) that master COM/COM+ use C/C++;
   
2. People that master SQL use C/C++;
   
3. People that master OOP use C/C++;
   
4. People best skilled in VFP usage use C/C++;
   
5. Many solutions to VFP API calls REQUIRES further understanding of C/C++ (say Windows internals);
   
6. Most of the people that thinks that VFP DOESN'T need strong data typing, structures and native VFP DML support to SQL engines, master OOP and all the above (BTW I think VFP should have srong data typing etc, as many other people here at UT think too - Hey MS VFP team! Please just don't say I must fill the form and..., think many already have done and talked about this here at UT)
   

OTOH, people that have VFP as his/her sole development tool:

1. It seems to me there are just a few masters (of any of the above's list subjects) among them;
   
2. Doesn't have abundant source of information at MSDN like VB and even Access, so they HAVE to learn how to "translate" from those languages to VFP to understand most of MSDN information;
   
3. Besides the efforts of Hentzenwerk (thanks Whill!) who else is publishing VFP books (ok, there is a "Special Edition Using Visual FoxPro 7 by Menachem Bazian" comming out of the oven)?
   
4. VFP books (with 2 or three exceptions, AFAIK) addresses just GENERAL VFP programming (the same is not true with, say, VB and Delphi (just take a look at Amazon, for instance and ask for "FoxPro" and select "list by publication date" to see what you get);
   
5. How can they better understand and use the most "advanced" features of VFP if they don't have a source of information about those subjects if they don't use C/C++, can't "translate" articles from VB to VFP, and don't have books about that stuff that is directed to a VFP audience?
   

The following are concerns of the foreign audience (mostly to the non North America's and non english speaking people). How can they get the juice from VFP if:

1. There are no localized version of VFP in many idioms? So, many times, the help files are useless;
   
2. There are no books about some subjects (please see the above list), and no translated VFP books at all about ANY subject;
   
3. Most of the foreign VFP community can't afford attending at overseas courses, DevCons, seminars etc, and there are NONE of these at their countries? So that's another reason they CAN'T learn more about VFP specific issues
   

My conclusion? Learning C/C++ might not be the best solution to lots of VFP people's problems, as I can see now. What could be done to change this picture? Sorry, don't know.

Very important note: All the above represents my perception. I may be wrong!

Regards,

Fernando