With VFP7's new ability to do TextMerge to a memory variable, I think VFP would have an edge.. but it needs to be on a level playing field, not weighted as George has said.


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