It's probably just the age old problem of binary versus ascii output for DOS IO.

Try this:

code:
"This line contains only a chr(10) " chr(10) "in the middle" ?

Now, if the output is binary i.e. exactly what you are attempting to send, then the "in the middle" part of the string would start on the next line, one space to the right of the first part of the string. It doesn't though, it starts at the beginning of the next line.

This is because the console output is an ASCII stream, and converts CHR(10)->CHR(13)+CHR(10).

If the output stream is binary then the conversion is not done - this would be the case where you want to copy a file for instance.

Unfortunately due to a moment of extreme madness when DOS was being cobbled together, the engineers decided to use CHR(13)+CHR(10) as the end-of-line sentinel for DOS IO, and programmers have been cursing them for it since that day.

So, it depends on what you intend to use the data for whether the data will be binary or ASCII. In the DOS world the programmer will have to guess, and it will be wrong for someone.

Here is a good example of how it breaks things.
I have a file with 3 lines in it, each containing the number 1-3 in reverse order, the lines are seperated by CHR(10). If I "type" the file I get:

code:
3
 2
  1

So, "type" is preserving the information in the file - it is displaying it exactly as it is. What if I "sort" the file? Now I get:
code:
1
2
3

So the "sort" has converted my data - it has changed the end-of-line characters and inserted CHR(13)s.

So, sometimes the CHR(10)s are converted and sometimes not. It is down to the individual programmer to decide which is correct for each situation.

Personally I think you should always preserve the integrity of the data stream unless you are outputtiing it to a rendering device such as the screen of printer.

[ 30 January 2002: Message edited by: Richard Howarth ]