Dave,

now that's a nice tip. I was also trying to increase the speed of my log writing class. It initially wrote it with FPUT's etc (the hard way) and thought that using CREATEOBJECT("Scripting.FileSystemObject") would be faster...it wasn't. I will now look at your textmerge suggestion to see how this one works.

Thanks.

Ron

>Ron,
>
>I'm the first to admit that VFP isn't always the fastest solution. A lot of string manipulation like this can be done a few to several orders of magnitude faster in a language like C/C++. There are a couple of examples over on my website that show how to create a DLL using C++ and call it from VFP.
>
>I was just trying to say that there was probably alternate plain VFP code that would have been a lot faster.
>
>I helped a guy rewrite some code that was building a text output file with strtofile(,,.t.) commands in a loop and they complained about how long it took. Well all the time was being wasted in the file system I/O activity that technique requires. I suggested he swtch to using a single SET TEXMERGE with \\ commands in the loop, it was 100 times faster.
>
>>I didn't blame VFP for that. The point was that the file needed to be parsed to get it done. With regular expressions I just needed to look for a pattern (telephone number) and do the crunching from there. Even this solution was done from within VFP (!), we just took a little side-step to get faster results.
>>In the end everybody was happy because we reduced the process to seconds and not minutes.
>>
>>I sometimes like to think outside of the (VFP)box to get results. Don't get me wrong, VFP is more than great for what I need to do.