>>>1. not being able to subclass every control visually
>>True, but when does this really come into play?
>It would be extremely handy to subclass dataenvironments and headers.

I forgot DEs. :-(


>>>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.
>>Also, remember that some things are "By Design", even though
>>they look like bugs at first glance....
>Sometimes, IMO, the By Design arguments seem to be cover for poor design
>or an attempt to cover a bug.

Like, say, the View Designer? :-)

>I've had many, but one of the more weird problems I have had is having
>to requery() twice in a row.

Oh, lovely. Wonder what set that up....

>But I am currently working on a commercial shrink-wrapped product, and
>I am finding that I write crucual user interface code that no VFP feature
>can compensate for.

Which is why MS added it to Visual Studio, and people have been saying for
about a year now that we can't just be FoxPro programmers: we must be Windows
programmers.

>>>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.
>Copied from other part of thread: This is not feasible. The only way to
>send table/cursor data through ole automation to VB/VC++ is with a string.

What about ODBC? Have you tested that for speed?

>Have you ever timed FoxPro string routines???? They are performance dogs!

I've heard that this may be fixed in the next version...

>>What kind of product is it? When you finish, will the data handling parts
>>of it run faster or slower than they do now?
>Well, since that version of the app will be a client server app, the database
>handling becomes a moot point.

Myth! Myth! (Yeth?) :-)

You can still write a client-server app that does enough client-side processing
for the database handling to be a time factor. Of course, that doesn't mean yours
does, or should...

>I have heard a rumor that Microsoft will be shipping one with its next version
>of Visual Studio.

Yeah, I've heard that rumor, too, but nothing since. However, a FoxPro back end
might as well be SQL Server Lite: it's fast, and it would be easier to
administer...