>>From the VFP web site:
>>
>>Why would I build a component in Visual FoxPro when I can build the same component in Microsoft Visual Basic® or Microsoft Visual C++®?
>>
>>Visual FoxPro components are extremely fast, thanks to the data-centric language of Visual FoxPro and its ability to quickly retrieve and manipulate data. Further, Visual FoxPro can build character strings very swiftly. A Visual FoxPro component that works with data and returns HTML will, therefore, be very fast.
>>
>>Visual FoxPro also has object-oriented programming capabilities, including inheritance. This provides a high degree of reuse across applications. A Visual FoxPro developer can create a set of classes that includes the core functionality of a Web database component, so that code will not need to be rewritten each time a component is needed in a Web application. The developer can simply create a component that inherits the base functionality, and then add application-specific code to it.
>>
>>Finally, building COM components in Visual FoxPro is an excellent way to reuse existing code. Code that is already written and tested can be built into a component, rather than being recreated in another language.
>>
>>
>>http://msdn.microsoft.com/vfoxpro/prodinfo/qa.asp
>
>Wasn't string-manipulation the theme for last year's VFP vs. VB showdown in the off.ramp at devx? Or was that combined with low-level file functions?

Yeah, but it was heavily weighted in VB's favor. The challenge combined file I/O and string manipulation. Among other things, VB had the advantage in the file I/O area since the test involved opening a file of a given structure, one of who's members was an IEEE format 8 byte double precision floating point number. I think also that there was some array stuff involved with the array being in excess of 65,000 elements.

>In any case, in the context of generating HTML from VFP cursors I can see how VFP would be faster. I guess a test is at hand.