AFAK, ATLINE and ATCLINE existed even in FPD2.6. Both functions use the chr(13) as line terminator. This is good to know especially when your data comes from a mainframe or other Unix system that uses the more common chr(10) as line terminator.

Considering the help for ATLINE, I would say that it's a bug in this particular situation (because it says that it searches for a memo field within another memo field and a memo field can contain chr(13)).

When I needed to do such searches, I wrote my own function and it was not very elegant. Something like:

lnAt = AT(lcSearched, lcText)
IF lnAt > 0
*-- The line number is the number of line terminators
* before the searched string, plus 1
lnLine = OCCURS(CHR(13), LEFT(lcText, lnAt - 1)) + 1
ELSE
lnLine = 0
ENDIF
RETURN lnLine

Such function can be slow when your strings are very large, but it works with any characters inside the strings.

Vlad

>VFP 6.0 has a new command ATLINE and ATCLINE which is nice for qiuckly getting to a line in a string. This is handy if you need to line based parsing of strings.
>
>Unfortunately there's a bug (feature?) that causes ATLINE to fail if you look for strings that contain CHR(13) or for strings at the end of a line that have trailing spaces:
>

>lcText = "Hi..." + CHR(13)+"Hello World  "+CHR(13)+"!"
>? ATCLINE("World ",lcText)
>
>lcText = "Hi..." + CHR(13)+"Hello World  "+CHR(13)+"!"
>? ATCLINE("World"+CHR(13),lcText)
>

>Both of the above fail making it impossible to search for an exact
>match that may occur at the end of a line.
>
>Ok, so that's out. Any suggestions on how you could do this
>efficiently? I need to get a line number into a string in order
>to be able to go forward and backwards through the file. Parsing
>with MLINE won't work either, because it'll never retrieve a
>CHR(13) either.
>
>Any ideas how else to get a line pointer?
>
>+++ Rick ---