In a 'regular' ASCII text file output by Notepad you will find that the end
of line sequence is 2 bytes, decimal value 13 followed by decimal value 10.
If the 13 does not preceed the 10, then it's not recognized as a new line.
That is CR followed by LF.

I'm thinking if you can define how to terminate each line on the Unix side
you should be able to output so that Excel can input with the code you have.

There's a good write up about it all over in Wikopedia at
http://en.wikipedia.org/wiki/Newline
Even gives some programming 'work-arounds'.

"Pflugs" wrote:

I have been exporting model trees as text files from our modeling program
(running on Unix), and then FTP'ing them to my Windows workstation. Because
of the way the program outputs the files, I use a question mark ("?") as a
delimiter. Many times, commas, dashes, spaces, and slashes are used in the
data's columns, so the common delimiters are out.

Sometimes the files contain over 100,000 lines, so I tried using the code
Microsoft suggests to import the lines to multiple sheets. However, I think
the code read the entire file as one line, for it tried to place the entire
file into "A1." Sure enough, when I opened the text file with Notepad, it's
all one line. But, if I open the file with Wordpad, the lines are correctly
displayed. If I save the file and reopen with Notepad, the lines are
correctly displayed. How do I workaround this?

(By the way, I did go in and verify that there were "Chr(10)'s" where
Notepad displayed boxes.)

Also, most of the lines in the text file are blank or contain a handful of
spaces and then a question mark. Is there a way that I can force the code to
only import lines that contain actual data? How fast is this compared to
opening the whole file (assuming it will fit) and running a for loop to
delete the blank lines?

Thanks for your help,
Pflugs