>>
>>Peter
>>
>> Could you please be more specific on what you feel the limitations
>>in the VFP user interface are and what other languages are
>>better and in which ways. Also what is the language you chose to use
>>in your new project.
>>
>>thanks Gary
>
>I guess the main problems I find with the VFP user interface are the inconsistancies:
>1. not being able to subclass every control visually
>2. some very interesting quirks with the grid (esp being slow when it is sized very large; this also happens in browse windows)
> a. Properties that do not behave the same in a grid and outside a grid
> b. Scrollbars that do not synchronize very well with the data (to make it synchronize, you need to refresh after every afterrowcolchange event
>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.
>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.
>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. You can NOT tell me that VFP has no bugs, because I have seen them with my own eyes.
>
>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. 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. I guess for the most part it is possible to do anything you can think up in VFP, but the solution might be too slow, might require an ActiveX control (which means you write C++ or VB code anyway), or it could be infeasable. For example there is no way to get VFP to do multiple threads.
>
>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. 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.
>
>To answer your question, I am planning on writing the next version of my product in MS Visual C++.
>
>HTH,
>Peter

Peter

I understand many of your criticisms of VFP. I have encountered
many of the bugs before in VFP. I have pulled my hair out extensivly
in trying to decipher these quirks. I also come from an MFC environment
and had a suite of programs developed of which some were in C++. I
eventually converted the C++ sections over to VFP because of the
database tools in VFP. I don't know why someone doesn't come up (at
least that I've seen) with extensible query tools for MFC. I was using
Codebase before and they had taken way too long to come up with the
activeX version of their C++ controls. I find that it is so much easier
to develop in VFP once you get over the learning curve.

Any others have comments?

Gary