TextArea, suppress CRLF Symbol

Targets macOS
1

Make the TextArea.String CRLF functional but suppress the CRLF symbol

2

You see a CRLF symbol in your TextArea ?

3

You probably need to set the encoding of the string. See DefineEncoding and ConvertEncoding in the Language Reference.

4

I noticed the same thing. If I read a text file with EndOfLine.Windows → MyString ;
Then MyTextArea.Text = MyString
And MyString = MyTextArea.Text then the EndOfLine are now macOS .

5

Right. When reading text files that you don’t know the origins of, you should be calling ReplaceLineEndings to get the line endings in line with what your program expects.

6

I don’t know if it’s changed since last Xojo update or if it’s my memory, but in this sample project Test-CRLF-TextArea
On Mac I have the EoF I set, but on Windows, when I paste a string in a TextField I have EndOfLine.CR (= EndOfLine.Macintosh that may be why I don’t well remember as now on Mac we use EndOfLine.macOS = EndOfLine.LF)

Run the project, click “PushBtnPasteEofLF” and then “Search” buttons.
Do it again with “Paste Text EofCRLF”.
It’s ok on Mac but we always find EndOfLine.CR on Windows (Windows 10).

7

I actually just ran into this in a Windows port. I have a user-filled textarea and, on Mac, I get EndOfLine = LF (0x0A), but on Windows, I get just CR (0x0D). Since I’m trying to split on EndOfLine to parse the entries, the cross platform solution has to be:

lines = textarea1.Text.ReplaceLineEndings(EndOfLine).Split(EndOfLine)

I had assumed that, per EndOfLine documentation, all of the platforms have LF in there somewhere and had been splitting on that (with a Trim to get rid of any CRs that might be in there), but it obviously broke. Unfortunately, what I assumed would then be the right answer (splitting on EndOfLine) also didn’t work, necessitating the ReplaceLineEndings. Seems a bit strange to have to ReplaceLineEndings for text of known origins (i.e. from within Xojo) where the replacement is what you would expect it to be in the first place. I’m happy that, at least in this case, ReplaceLineEndings figures it out.

Have to go back and look, but wondering if this causes other problems, like in copy & paste?

8

Thanks to you all for your info.

I have made changes to reflect the points you have made. There have been other modifications to cleanup some issues related to Strings from Memory blocks. However, the problem has not changed so that 'Strings passed to the TextArea do not trigger a CRLF but place an “Unprintable” symbol in its place".

Clearly, TextArea is controlling sentence length because, there are breaks in the sentences in the TextArea. I have searched for some time to try and find if there is a setting that disables the CRLF (when required). Unfortunately, nothing in the documentation addresses the issue. Likewise, if there is such a facility, I would like to set it.

9

I just made a test with 2021r1 on a M1/Big Sur 11.2.3 and copy/pasted text from textedit document: no CRLF is displayed.

A Copy / Paste of this page does not display strange character too.

Care to provide a project example and eventually a text file ?