>>
>>lcCr = CHR(13)
>>lcLf = CHR(10)
>>lcTab = CHR(09)
>>
>>...
>>
>>
>
>Yep and CHR(12) as that's a form feed. I'm actually just checking for anything that's ASCII value is less than 32 to make sure I get them all.
>
>>You would want to check data used to create file because file itself will include CrLf as EOL
>
>Ok I don't know what you mean by that. I created the file myself using FWRITE - what is CrLf? isnt' that chr(10)?
>
>What I'm finding is that every line ends with CHR(13) CHR(10)
that is CRLF ;-)
.....which is what I wanted to do and the line this guy claims has some other thing at the end of it doesn't look any different to me than all the other lines. I really think he just might of made a mistake but I really don't wanna tell him that unless I'm like 1000% sure I've checked the file myself properly..hahahaha
old unix used only LF, DOS operates just on CR without problem, CRLF supposed to work across.
>
>
>>>I'm creating a text file which is basically an export of some data.
>>>
>>>The problem I seem to be having is that when the guy who's using this file tries to import it, he's saying that I must have some embedded carriage returns in some of the lines. Of course I open the file with wordpad or ultraedit or whatever I don't see that problem. However before I say "I don't think so" I want to be sure this isn't happening. Perhaps one of the data-fields I'm grabbing has this in it.
>>>
>>>So here is my question. How can I look through a text file with VFP and search for carriage returns, line feeds, or whatever else might cause this?
lcTxt = filetostr("myprecious")
local laErg[255, 3]
for lnChar = 1 to 255
laErg[m.lnChar,1] = lnChar
laErg[m.lnChar,2] = chr(lnChar)
laErg[m.lnChar,3] = occurs(m.lcTxt, chr(lnChar))
next
gives you enough data and structure to see in debugger or write out into table or print....