writeline behaving differently mac/win

General
1

I have developed a small address database using a listbox. The addresses are stored in a text file with each entry on a new line (name, address postal code, town, empty line) to be easy to read and edit manually.
It works perfectly on my osx mac, but when I compile and run it on windows and use a file saved on my mac, the empty lines added by t.writeline () are skipped for some reason. If I save on the windowsPC, then it opens fine on both win and osx. I am opening the file as UTF-8.

The weird thing is that if I replace t.writeline () with t.writeline(ListBox1.Cell (0,0))
Then the extra line is not skipped and it works, but I would like the empty line in the file!
I also tried to replace with t.writeline str("") and a bunch of other fun, but without result.

Of course I could add an empty listbox cell as a work around, but I would like to know what is going on.
(-Something with LF/CR?? -If so, what should I do?)
What am I doing wrong? Am I not automatically writing utf-8? Does utf-8 not cure the LF/CR compatibillity issues?

…
if f <> nil then
t=TextOutputStream.Create(f)

  for d=1 to c
  t.writeline(ListBox1.Cell (a,b)) 
  b=b+1
  t.writeline(ListBox1.Cell (a,b))
  b=b+1
  t.writeline(ListBox1.Cell (a,b))
  b=b+1
  t.writeline(ListBox1.Cell (a,b))
 
  t.writeline ()   'to separate entriies with empty line in the file (osx saved file does not work on win)
                          'Replacing with t.writeline(ListBox1.Cell (0,0)) works but adds junk

  b=b-3
  a=a+1
next d
t.close
2

On Windows write line use the normal Windows CR/LF end of line
On OS X it uses the OS X newline
And if you move a file from one OS to the other then you have issues

UNLESS you use ReplaceLineEndings when you read the file back in

3

The formats UTF-8, UTF-16 etc does not make a difference when using writeline?
To make the files identical, saved from osx/mac, saving a textstream instead helps?

It is still weird that t.writeline () written to file on OSX, is skipped on Windows, while t.writeline(ListBox1.Cell (0,0)) is not.(?)

4

You said t.writeline(ListBox1.Cell (0,0)) adds junk.

The easiest way to save a file to be opened on Windows is instead of writeline :

t.write("whateverstring"+EndOfLine.Windows)
5

No idea whats up

Here’s what I did

  1. created a new desktop project
  2. added a listbox with column count set to 3
  3. added a bevel button
  4. in the listbox open event added this code

for i as integer = 0 to 4 me.AddRow "row " + str(i) + " col " + str(0) for j as integer = 1 to me.ColumnCount - 1 me.Cell(i,j) = "row " + str(i) + " col " + str(j) next next

  1. in the bevel button action event put this code

[code] dim f as folderitem = SpecialFolder.Desktop.child(“some random folder”)

dim t as TextOutputStream = TextOutputStream.Create(f)

for i as integer = 0 to Listbox1.ListCount-1
for j as integer = 0 to listbox1.ColumnCount-1
t.writeline(ListBox1.Cell (i,j))
next
t.writeline () 'to separate entriies with empty line in the file (osx saved file does not work on win)
next

t.close

[/code]

  1. hit run
  2. pressed the bevel button

My file looks like

[code]row 0 col 0
row 0 col 1
row 0 col 2

row 1 col 0
row 1 col 1
row 1 col 2

row 2 col 0
row 2 col 1
row 2 col 2

row 3 col 0
row 3 col 1
row 3 col 2

row 4 col 0
row 4 col 1
row 4 col 2[/code]

exactly as I would expect

6

Yes. But not after having moved the file from osx to windows. As I said my app worked fine in OSX, but failed to open the file (saved in OSX) correctly in Windows…

After fiddling for hours, I did what I should have done from the start. I examined the file with the terminal tool “od”:
using od -c thefilename -It is clear that the source of the problem is that:
t.writeline(ListBox1.Cell (a,b)) generates CR and LF
t.writeline(“blah,blah,blah”) only generates CR

-Inconsistent and confusing behavior. I don’t understand why and can’t find it specified or documented anywhere.

@Michel Bujardet
-Thanks. -Replacing t.writeline () with t.write(""+EndOfLine.Windows) did it. CR and LF are generated. The OSX made file now also opens correctly on the windows version of my app.

7

[quote=129428:@Roger Jönsson]Yes. But not after having moved the file from osx to windows. As I said my app worked fine in OSX, but failed to open the file (saved in OSX) correctly in Windows…

After fiddling for hours, I did what I should have done from the start. I examined the file with the terminal tool “od”:
using od -c thefilename -It is clear that the source of the problem is that:
t.writeline(ListBox1.Cell (a,b)) generates CR and LF
t.writeline(“blah,blah,blah”) only generates CR

-Inconsistent and confusing behavior. I don’t understand why and can’t find it specified or documented anywhere.
[/quote]
I cannot duplicate this
Same app but added one line to the button a code so its now

  dim f as folderitem = SpecialFolder.Desktop.child("some random folder")
  
  dim t as TextOutputStream = TextOutputStream.Create(f)
  
  for i as integer = 0 to Listbox1.ListCount-1
    for j as integer  = 0 to listbox1.ColumnCount-1
      t.writeline(ListBox1.Cell (i,j))
    next
    t.writeline( "blah blah blah")
    t.writeline () 'to separate entriies with empty line in the file (osx saved file does not work on win)
  next
  
  t.close

Everything on OS X is still simply separated with CR on every line

TO take this file to windows & open it correctly I would need to do something like

  dim f as folderitem = SpecialFolder.Desktop.child("some random folder")
  
  dim t as TextInputStream = TextInputStream.Open(f)
  
  dim allText as string = t.ReadAll
  
  dim lines() as string = split(ReplaceLineEndings(allText, EndOfLine), EndOfLine)
  
  Listbox1.DeleteAllRows
  dim j as integer
  dim k as integer
  
  for i as integer = 0 to UBound(lines)
    if j = 0 then 
      Listbox1.AddRow ""
    end if
    if lines(i) = "" then
      j = 0
      k = k +1
    else
      Listbox1.Cell(k,j) = lines(i)
      j = j + 1
    end if
  next

This code works on OS X and Windows unaltered (I literally just copied from OS X to Windows 7 and ran it)

The KEY in READING is the line with the split & replace line endings which makes it do you DO NOT care what the native line endings are when the file is written
When the same code writes the file on Windows all one endings are CR + LF but I can read it just done on OS X and vice versa

8

Reading the line with the split & replace line endings, is another way around the problem?

t.write(""+EndOfLine.Windows) fixed my problem and now both osx and windows version adds both LF and CR for each line and both reads it in correctly. -But for safety maybe it is better to do the split and replace also?

When you say that you cant duplicate my problem, did you check the file written on OSX with a tool like od to confirm that you get CR ONLY on every line? When I do it I get CR -AND- LF when writing listbox content and CR only writing a string. (xojo 2014 2.1)

9

I used exactly the code I posted
I opened the file in a hex editor & confirmed that line endings were correct in every case

10

Using Endofline.Windows will work for your app, but if other apps might open your files then it is not a good idea.

Using ReplaceLineEndings will always work.

11

@ Norman Palardy -Ok. Thanks. It is strange that the line endings differs here, depending on writing a string or listbox cell (OSX). I will do some more testing to try to find out what is going with the line endings. It shouldn’t do this. Irritating… I get it that it differs OSX/Windows, but not that it differs on OSX (on my computer).

I get it that doing ReplaceLineEndings is the better way to go.
Although the wordprocessors etc on my Mac seems to handle the Endofline.Windows files correctly, I am not sure what is the best way to go (writing text files). Keep using Endofline.Windows or let it be whatever writeline decides. Hm…

-Thanks all.

12

[quote=129639:@Roger Jönsson]I get it that doing ReplaceLineEndings is the better way to go.
Although the wordprocessors etc on my Mac seems to handle the Endofline.Windows files correctly, I am not sure what is the best way to go (writing text files). Keep using Endofline.Windows or let it be whatever writeline decides. Hm…[/quote]

What happens when loading the generated file :

Endofline Mac Windows Mac OK No Windows OK OK

13

Sigh. I apologize for waisting your time.

The source of the evil was that I used a test file with the addresses, exported from another database when doing the final tests and moving it all over to windows. The CR+LF obviously survived when opening the file and got saved in the same way. When opening the file mac version seems happy with either LF or CR+LF, while the windows version is not.
How stupid of me not to think that the LF+CR could have come from the old file I used. I just assumed that when the text was in the listbox cells it was just the text visible and did not think of hidden signs. When I examined the last file created before I stopped using writeline, I can see that the last few new entries (large file) saved from OSX does not have LF+CR. Had I scrolled to the bottom I would have seen this. Not understanding the source of the problem, making false assumptions, I didn’t see it by not looking at the right place.
At least I learned something more about line endings and text. -And testing. [embarrassed]

Thank you all for trying to help.
Using ReplaceLineEndings is the way to go when opening text files.

14

Saving the file with Windows line ending seems prudent, though, in case it should be used in another app.

15

Yes, but it seems that OSX wordprocessors etc handles CR+LF ok, while Windows programs handling varies more and often generates no newline with only LF. So if the files are to be moved between OSX and Win, this is MAYBE the best way and most likely to work at any of the two systems.
The reason for saving to an open format text file, is to be able do some operations in a simple wordprocessor if needed and to always have a file that can be easily imported to another database. Otherwise some sort of non-textfile would have been better. I guess…

16

[quote=129662:@Roger Jönsson]Yes, but it seems that OSX wordprocessors etc handles CR+LF ok, while Windows programs handling varies more and often generates no newline with only LF. So if the files are to be moved between OSX and Win, this is MAYBE the best way and most likely to work at any of the two systems.
The reason for saving to an open format text file, is to be able do some operations in a simple wordprocessor if needed and to always have a file that can be easily imported to another database. Otherwise some sort of non-textfile would have been better. I guess…[/quote]

That is what I said : always use EndOfLIne.Windows, which if CR+LF, and it will work fine everywhere.

17

I realize that I didn’t really understand the meaning of the word prudent. Sorry about that. (English is not my first language).
Now I know. Thank you!

19

I disagree. Doing this can cause unexpected problems with your app. If you read in the string

test

Your variable will contain “test” and tests such as

if datafromthefile = “test”

will fail, because “test” <> “test”

Use the line ending native to the machine and deal with cross-platform issues in the normal manner. Any time you move a text file from Mac to Windows (or *nix to Windows), you have the same problem, regardless of what app created the file. Many transport protocols, such as FTP will adjust line endings for you, to compensate for this issue.

20

or, if you use an app you wrote in Xojo, use the few lines of code required to make it so you don’t care about line endings :stuck_out_tongue:

21

[quote=129758:@Tim Hare]I disagree. Doing this can cause unexpected problems with your app. If you read in the string

test

Your variable will contain “test” and tests such as

if datafromthefile = “test”

will fail, because “test” <> “test”

Use the line ending native to the machine and deal with cross-platform issues in the normal manner. Any time you move a text file from Mac to Windows (or *nix to Windows), you have the same problem, regardless of what app created the file. Many transport protocols, such as FTP will adjust line endings for you, to compensate for this issue.[/quote]

If you read in your Mac, you should have taken the elementary precaution to use ReplaceLineEndings, so whatever is used will end up fine. That is necessary with ReadAll. I just tested ReadLine, and no CR in the line.

If you save a file with EndOfLIne.Macintosh and hand it to a Windows user, he will have a document with all the content on the first line.

Now when that individual will question the validity of the file, is it better to tell him he should know better, or to save in a format that will be recognized by his machine ?

I do not believe it is good form to say

PC users had the bad habit to look down on Mac users for exactly the same reason the other way around. Then Apple worked on that issue and solved it. There is no reason a good programmer should not be kind enough to make it easy for other platforms to open text documents.

If necessary, an “export” option can be provided, to respect the sanctity of one’s favorite platform …