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