>>>>LPARAMETERS tcText
>>>>LOCAL lnLines,lcText,x
>>>>LOCAL ARRAY laLines[1]
>>>>lnLines=ALINES(laLines,m.tcText,1,",")
>>>>lcText = laLines[m.lnLines]
>>>>FOR x = lnLines-1 TO 1 STEP -1
>>>> lcText = m.lcText + "," + laLines[m.x]
>>>>ENDFOR x
>>>>RETURN m.lcTextvfp
>>>
>>>Just want to add that in my testing, ALINES() are much, much faster than the GETWORD*() functions. For a short string, it probably won't make much difference, but done repeatedly or for long strings, it'll be visible. (Mike, I know you know this; adding it for Rick.)
>>>
>>
>>YMMV on this. I know that ALines often is faster - but did check in one special instance with rather low word count and no special cParseChar to given on the GetWord* function, but added to alines(). In this special case GetWord was faster (measured with own C-framwork, not depending on HD/SSD speed of vfp coverage).
>>As always, measure if important ;-)
>
>As I spelled out later in the thread, the performance of ALINES() grows linearly. Pretty much every other way of parsing a string grows faster than linerarly.
>
>>Also, if working on huge strings, single concat in loop will slow down exponentially due to memory copy of existing string, which gets larger on each copy. To get more stable times in such cases copy into intermediate array with 100 - 1000 words for each intermediate array element, concat those lines at the end in 10 or 20 array lines on each step but the last ;-)
>
>Not my testing, but pretty sure Steve Black showed fairly conclusively that adding to the end of string is always fast, but adding to the front can bog down. Talking about his seminal paper: http://stevenblack.com/articles/text-and-string-handling-in-VFP/
>
>Tamar

I can confirm it.

MartinaJ