>>>>Nadya,
>>>>>>
>>>>>>I've never found a problem with speed with the library. I'm not saying one doesn't exist, just that's it's not been my experience. Further, as I noted to Russell, this functionality will be in VFP 7.0 so, under the circumstances, there's no reason for me to change my recommendation. Thanks for the input, though.
>>>>>
>>>>>George,
>>>>>
>>>>>I've found this thread, check it out:
>>>>>Coding, syntax & commands Re: String parsing Thread #273042 Message #273482
>>>>
>>>>Undoubtedly, when parsing "large text files" there is a speed gain. However, this doesn't necessarily make this the same as parsing a "string". In some cases, yes, in some cases no. In the example given, I would take my method each and every time. There's less code to maintain, and the performance issue, as far as I am concerned, is totally moot.
>>>
>>>Well, at that time I also compared speed in this method and Charlie's
>>>Coding, syntax & commands Re: String parsing Thread #273042 Message #273134
>>>(code, I posted). This was as fast, as Cetin's FLL and the code is very simple.
>>>
>>>In any case, if the string is small (few words), we should not worry about speed. Otherwise I would suggest alines approach.
>>
>>I wouldn't. The solution works with only a single delimeter. Words and WordNum can work with multiple delimeters.
>
>It works with multiple delimiters too. See strtran(lcStr,"**",chr(13)) works just fine. I had strtran() in my original program. For a moment I thought about chrtran(), but almost immediatelly understood, it would not work for multiple delimiters.

You're wrong, not the same way. I think you misunderstand what's meant by multiple delimiters.

lcstring = "text1,text2:text3;text4"
? Words(lcstring, ",;:")

STRTRAN() won't do that.