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.