>>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. These are the main ones, but cursor objects could be helpful to. You can already do that in code (use a prg to subclass), but you cannot drop a prg class into a visual form, etc.

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

For example, sometimes they are in a disable state even though you can click on them to scroll. Also, the visual behavior is changed when refreshing in every afterrowcolchanged (visuall more exact) as opposed to not refreshing. I don't know how else to prove this to you if you have never seen this.

>>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....
>
:) True. It seems that MS did very little testing when shipping the VB beta controls with VFP

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

Sometimes, IMO, the By Design arguments seem to be cover for poor design or an attempt to cover a bug. Sometimes the By Design argument actually fits the scenario. I've had many, but one of the more weird problems I have had is having to requery() twice in a row. Must have had something to do with VFP's internal state not being quite right.

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

Yah, but the implementations that you see on Wintel machines is Just in time compiled, meaning that it is quickly translated into native code. Just try comparing Java on Win95 to Java on Linux (which doesn't have JIT) sometime. Its true that if you can stick to rushmore optimized database commands, than you can outperform VB5 (which has a 'native' compiler). And most C++ apps that don't have highly optimized database engines. 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.

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

My programming methodology is to dream up some scheme, which I usually know can be done in C++ and for which I know the algorithms involved, etc., and then I try to implement them. This of course is not safe in VFP. That is why I am so frustrated with VFP.

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

You just got to employ safe programming :-)

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

That is the problem. I chose the wrong tool, I admit it. But I could live with the VFP feature limitations if I did not encounter so many bugs or so many poorly/half implemented features.

>>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. In VFP you would have to create something like a for...endfor loop that would sit there and concatenate each record so that it could be sent to VB. Have you ever timed FoxPro string routines???? They are performance dogs! I once had to lock a number of records at one time and I saw that the lock routine could accept either a recno or a series of recnos separated by commas in a string. As it turned out, creating the string became prohibitive. It was several hundred percent faster to create an array of all the recnos that I needed to lock and then with a for...endfor loop lock each record.

I have nothing against the FoxPro string handling system. It is optimized for ease of use and for short string handling operations. At the Fox devcon one of the sessions stated suggested to use the FOpen/FWrite file handling operations to write out the information you needed to disk and then to read the temporary file into a string from disk. Amazingly enough this operation was much faster than string concatenation! So until FoxPro creates a mechanism to send large amounts of table information via an ole, using Fox as an ole backend is out of the question.

>>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?
>
Well, since that version of the app will be a client server app, the database handling becomes a moot point. For those customers that need a smaller solution we hope to employ a scaled down SQL server (like Sybases' SQL anywhere). I have not reviewed the smaller versions of SQL products, but I have heard a rumor that Microsoft will be shipping one with its next version of Visual Studio.

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

Right...