>1. not being able to subclass every control visually

True, but when does this really come into play?

> b. Scrollbars that do not synchronize very well with the data
> (to make it synchronize, you need to refresh after every afterrowcolchange event)

Not in my experience.

>3. poor integration of ActiveX controls. This is not always FoxPros fault--often
>the ActiveX controls are buggy, but I would have hoped that the controls that
>shipped with VFP would be less buggy than most.

Unfortunately, the ActiveX controls shipped with VFP _are_ the same as the ones
shipped with the other products. If only MS would follow their own design
specs....

>4. spurious errors that make no sense in their context. Take 'Record
>is in use by another user.' error that occurs during a replace on a table
>that is opened Exclusive.

<*sigh*> Wish I could justify this one, but...

>5. The slow response Microsoft has towards VFP bugs. In all the Visual
>Studio service packs, the VFP patches have consisted of a few obscure
>bugs that I had never encountered. For other products, the bug fixes
>were extensive.

Maybe the others started with more. :-) Not a good argument without more
backup data. Also, remember that some things are "By Design", even though
they look like bugs at first glance....

>I could also complain about VFP in terms of speed of any of the
>interpreted code but that would not be fair, because VFP is interpreted.

So is Java, for the most part. Besides, the data handling usually more than
makes up for the interpreted code...

>Part of the problem might be that I am fluent in C++ and in VFP and that
>certain visual features that I could have implemented in Visual C++ in a
>couple of days end up taking a couple weeks in VFP because I have to
>come up with interesting ways to break out of the VFP mold.

Or, you could work with it, rather than against it. I've found that this
usually works quite well....

>For example there is no way to get VFP to do multiple threads.

I don't think I'd really want multiple threads working with my data: can
you give an example of when this would be a good thing? (One that comes to
mind is a newsreader application, but...)

>It all boils down to: you can do a whole lot of stuff in VFP, but to
>create a slick product grade program is either impossible or requires
>more work than it would take in another language.

Wrong. You can create very slick products in VFP, unless you're trying to
write C++ programs in it.

>I would love to use the VFP database engine in another environment;
>for example Microsoft could distribute the VFP database engine in much
>the same way that they distribute the Jet database engine (Access, VB)
>now.

You can expose VFP as an automatable object.

>To answer your question, I am planning on writing the next version of
>my product in MS Visual C++.

What kind of product is it? When you finish, will the data handling parts
of it run faster or slower than they do now?

The right tool for the right job, remember. :-)