Bug? CRLF - Maybe a bug, maybe not

[Peter Simpson]

Hello Erel,
In B4J when I write to a file and I then use '& CRLF' at the end of the line, I've noticed that in Notepad++ even though it is putting each line written onto separate lines, it is actually showing LF and not CRLF at the end of each line as I would have expected. Just as a test, I then opened the file in M$ notepad and basically all the lines were showing on just one line.

The screen shot below is not of the file in question, but I have written 1 line using B4J to show you. Please look at the screenshots below, you can clearly see that in B4J I've added CRLF to the end of the line.

In Notepad++

B4J line

I've not tested it in B4A, but I do know that in vb.net if one uses & VbCrLr in Notepad++ at the end of each line it does in fact show CRLF and not just LF.

BTW, I've not used Chr$(10) in years

Thank you...

 

[moster67]

Maybe this?

Probably the keyword CRLF is implemented as a LineFeed which is probably fine for Linux-systems such as a Android i.e.

CRLF = "\n"

In B4J, perhaps the keyword CRLF should use, under the hood, the System.lineSeparator() method which automatically detects the operating system.

What happens if you write in B4J:

FileLines = FileLines & Setting & "=" & WriteValue & "\n\r"  'or "\r\n"

 

[DonManfred]

The screen shot below is not of the file in question, but I have written 1 line using B4J to show you. Please look at the screenshots below, you can clearly see that in B4J I've added CRLF to the end of the line.

It is not a bug.
See CRLF

CRLF As String
New line character. The value of Chr(10).

If you want CR AND LF then you need to use something like this

sub AddCRLF(text as string) as string
  return text&chr(13)&chr(10)
end sub

 

[Peter Simpson]

It is not a bug.
See CRLF


If you want CR AND LF then you need to use something like this

sub AddCRLF(text as string) as string
  return text&chr(13)&chr(10)
end sub

Thank you,
Well in that case Erel should change it to just LF if there's no carriage return, that's 100% misleading IMO.

It actually does not matter to my code I (it doesn't effect my code either way), but I was a bit shocked to check what I had written in Notepad++ and instead of seeing CRLF because that's what's what B4J clearly says, it just says LF.

Thank you for the info @DonManfred

Hmm, I might give that a go @moster67, cheers.

I still think that B4J should actually read just LF and not CRLF .

Cheers both...

Edit: I've just found this post https://www.b4x.com/android/forum/threads/crlf-strangeness.58632/#content

 

[udg]

This is a quote from Erel

I agree that it can be confusing and it should have been named different (EndOfLine maybe). However CRLF value (chr 10) is the "correct" end of line character on Android iOS and Java apps.

Probabily we can add a wish for CRLF2 returning 13+10 (0D+0A if you prefer), leaving CRLF as is so to no break existing code.

 

[MarkusR]

its a misleading constant because it contains 2 control characters in name.
maybe the compiler can write invalid/deprecated.
i suggest removing it and replace it just as LineFeed constant. and a correct one as constant CarriageReturnLineFeed

 

[Erel]

CRLF constant will never be removed.

https://www.b4x.com/android/forum/threads/crlf-strangeness.58632/#post-369286