>>>>This is odd, to say the least. The next line prints 13, indicating that the carriage return character is the last character of the third word. It should have been 108.
>>>>

? asc( right( getwordnum("huppel de puppel" + chr(13)+chr(10), 3 ),1 ) )

>>>>Is this a bug or is it by design? Who knows more?
>>>
>>>
>>>The 3th word is: "puppel" + chr(13)+chr(10) not just "puppel" :-) That is because default delimiter is space.
>>>Try:
>>>

>>>WAIT WINDOW getwordnum("huppel de puppel" + chr(13)+chr(10), 3 ) + [Test string]
>>>

>>
>>Two remarks here:
>>
>>1) The help text says: The default delimiters are space, tab, carriage return, and line feed. One would expect that all delimiters are removed/ignored in the resulting word, as is the case with space.
>>
>>2) The linefeed character is indeed removed.
>>
>>Are you suggesting here that it is by design? That it is a way to know where a line ends? In that case it should have been documented.
>
>

>WAIT WINDOW getwordnum("huppel de puppel" + chr(13)+chr(10), 3, " "+CHR(13)+CHR(10) ) + [Test string]
>

>
>Never relay on default values :-))))

You may be very right in this case. See this one:

? getwordnum("huppel de puppel" + chr(13)+"kaas kop"+ chr(13)+chr(10), 3 )

It produces 'kaasel'!! Apparently the carriage return is NOT in the default delimiter string. The proof:

? getwordnum("huppel de puppel" + chr(13)+"kaas kop", 3, " "+chr(9)+chr(13)+chr(10) )

The VFP7 help says: The default delimiters are space, tab, and carriage return.

The VFP9 help says: The default delimiters are space, tab, carriage return, and line feed.

The Hacker's guide for VFP7 says: Words are separated by space, tab (CHR(9)) and linefeed (CHR(10)).

It appears that the Hacker's Guide is the only one that is right. Perhaps someone got instructions to repair the documentation error. Instead of replacing 'carriage return' by 'line feed' this person has added 'and line feed'.