>Nancy,
>
>This line of code from your solution:
>
>lcName = RTRIM(STRTRAN(CHRTRAN(CHRTRAN(lcName, CHR(10), ' '), CHR(13), ' '), ' ', ' '))
>
>would be faster done like this:
>
>vfCRLF = chr(13) + chr(10) && don't use #define which is going to at runtime redo the concatenation over and over
>
>lcName = RTRIM(STRTRAN(CHRTRAN(lcName, vfCRLF, ' '), ' ', ' '))
>
>There are some other optimizations that could be done if VFP is proving to be way slower than VB.
df,
Do you have thoughts on the other "challenge"? I looked at it and immediately felt that it was weighted towards VB because of some of the instrinsic functionality that VB has that VFP doesn't. Example, and I reaching back here so I might be wrong about this, but doesn't VB have the ability to read in a part of a file as a specific type? The problem presented requires that an 8 byte double-precision floating point be read. To accomplish this in VFP, you'd have the additional overhead of converting a string. I thought about appending the info into a cursor with a single field (type B - dpfp), but I'm not sure I can get that to work. This doesn't mention that the suggested matrix size (1,000x,1,000) exceeds VFP's limit on array size.
Thoughts?
George
Ubi caritas et amor, deus ibi est