>>Why are the FoxPro forms (VFP 5.0a) still the slowest that I have seen in any Microsoft or Borland development tool? VC++ 5.0 and VB 5.0 as well as Delphi 3.0 (all products that I have evaluated) have forms which respond and refresh at more than exceptable speed, while my users complain about how slow forms are in my VFP 5.0 app. We are in the midst of slowly converting a FoxPro 2.6 (DOS) system to a Windows platform...
>>
>>Also, I have read that the more subclassed controls that one uses, the longer forms take to instantiate. What's the purpose of making VFP truly object-oriented if an already slow interface takes further performance hits? In my company, the owners don't want to hear that we need to replace all our current workstations (primarily P75's with 16 megs RAM) with P200's with at least 64 megs of RAM to get an app that performs at a decent level. I know my users do not like to watch pageframes refresh from one to the other...
>>
>>I also must vent about VFP's DBC. Why would I spend hours setting up all my tables with proper field mappings to MY classes only to have the WIZARDS totally disregard them? I would not call that RAD. In addition, why is the path to MY class library hard coded into the DBC? What's the point of having an IDE that allows me to specify additional classes and their locations (as well as provide further search paths) to only have the DBC tell me that it can not locate the class library and that it will remove the association? After all, I may want to work on the project at home where I do not have the same drive mappings as at the office!
>>
>>I see why most other developers do not respect VFP as a development tool, certainly not as a product for building robust applications. In fact, most professionals in Northeast Florida ask, "Why would you want to use FoxPro?" I look forward to a response from the hard core VFP developers out there...
>>
>>Regards,
>>J. Mendenhall
>>Manager, Information Systems
>>Reinsurance Management, Inc.
>
>From time to time we (UT members) have to see non-professional replies here and your reply (unfortunately) is one of them. Actually, you show total disrespect to many people (professionals) who do create robust app using VFP.
>The problem is following: for some reason someone cannot use VFP abilities (or use them poorly which is the same) and then start to blame the product instead of taking more time for learning.
>What do you mean saying 'slow form'. Did you make bench test? You know, it's not a problem to write poor interface or bad database design and wait for hours before the display using any language.
>In regard to subclassing. Yes if you wrap subclassing 20 times the result can be slow (but not necessarily), but who (in normal sense) will do this?
>Also, it's not necessary to 'spend hours setting up all my tables with proper field mappings to MY classes only to have the WIZARDS totally disregard them'. The truth is that 'professional' developers don't use paper wizards much. Their wizards are in their heads. At last, about the mapping. This question was answered here many times and actually it doesn't pose any problem for a developer. If someone is really interested to get answers (intead thrashing VFP and all of us) then post a question in polite manner as many people do.

I agree with Craig about rushing to judgement regarding an issue as subjective as user complaints about performance -- especially when the key phrase used was "converting from 2.6 to VFP". We have seen a number of seemingly minor coding changes that make an enormous difference in the perception of performance to our users. Permit me to list just a few: Depending upon how old the coding really is in the 2.6 app's you may have procedural coding building bars, or rows for selection in an object -- allow VFP to build these. Another is to avoid the changing of 'SET CENTURY' while a date field is being shown on a current form. Another is to begin the form's life cycle with the LOCKSCREEN=.T. and set it to .F. at the end of the INIT() for the form. Another is to carefully evaluate the need to fully populate all the objects on all the pages of a Page Frame -- we have found that we can bring some common object forward of the Page Frame and have them "appear" on all the pages as though they really were part of the page.