67930 - TextArea on Windows two end of line result in no end of line

Feedback Case Number: 67930

On Windows system:

TextArea1.Text = “”
TextArea1.Text = “Some test” + EndOfLine
TextArea1.Text = TextArea1.Text + “Some other text”

This code above results in one EndOfLine as expected, so the result is:
Some test
Some other test

But code that is adding twice EndOfLine gets no EndOfLine at all

TextArea1.Text = “”
TextArea1.Text = “Some test” + EndOfLine
TextArea1.Text = TextArea1.Text + EndOfLine + “Some other text”

This code results in:
Some testSome other test

But should have resulted in:
Some test

Some other test

Expected Result:
Two EndOfLine should be added

Actual Result:
No End of line is added


Use EndOfLine.CR because EndOfLine is CRLF which is converted when it’s sent to the Rich Edit 4.1 control to a CR. When CRLF’s are converted to CR’s the issue happens if there are two CR’s next to each other.

When you do

TextArea1.Text = “Some test” + EndOfLine '(this CRLF is converted to a CR before the next line is executed)
TextArea1.Text = TextArea1.Text + EndOfLine + “Some other text”

you are adding a CRLF right next to a previous CR so you end up with CRCRLF which causes the issue when it tries to convert the CRLF to a CR.

You can see this is the issue by splitting up the CRCRLF with a " " and it works as expected

TextArea1.Text = “Some test” + EndOfLine
TextArea1.Text = TextArea1.Text + " " + EndOfLine + “Some other text” + EndOfLine

This isn’t a xojo issue, its just how the control works.


But is not the whole idea with Xojo that it should mask out such platform specifics ?

There is no reason why the control could not replace what it gets if it has specific requirements internally instead of braking cross platform functionality.


Nice one :sweat_smile:


  1. You insert a “A” + CRLF
  2. The control converts that to “A” + CR, there is nothing Xojo can do about that.
  3. You ask what is in the control, “A” + CR is returned to Xojo
  4. Xojo replaces all CR with CRLF so you now have “A” + CRLF which is what you had originally
  5. You are happy

Someone else:

  1. They insert a “A” + CR because that is totally valid for the control in Windows
  2. They ask what is in the control, “A” + CR is returned to Xojo
  3. Xojo replaces all CR with CRLF so they now have “A” + CRLF which is not what they had originally
  4. They are not happy

They come on the forum and ask why Xojo is changing their stuff and complain that they don’t use Mac and it should work as expected.

You can get the text out of the control while converting CR back to CRLF by using SendMesage with EM_GETTEXTEX and GT_USECRLF - “When copying text, translate each CR into a CR/LF.”

There is also SES_XLTCRCRLFTOCR which can remove CRCRLF on the fly and replace it with a single CR so you don’t end up with missing line breaks but you will lose one of the CR’s so you won’t end up with your expected gap.

1 Like

I agree that the system is what it is, but I also understand why the author is puzzled. Indeed under Mac there is no issue, since it uses only CR.

Let us imagine someone creates a source under Mac, everything works perfectly, and that someone generates a Windows executable. Won’t work. Contrary to the claims of the company, Xojo is not behaving the same on both platforms. Textarea represents return as CR internally on both platforms, but under Windows, CRFL should transcoded upon entry into .Text.

It seems desirable that indeed, behavior be the same on each platform, transparently, as it happens for many other features. The user does not have to be concerned about a control inner properties.

Until this happens, a simple workaround is to use EndOfLine.Macintosh:

  TextArea1.Text =""
  TextArea1.Text = "Some test" + EndOfLine.Macintosh
  TextArea1.Text = TextArea1.Text + EndOfLine.macintosh + "Some other text"

The only problem here is the control automatically removing characters for obscure reasons. Again an absurd decision made by Microsoft…
And then, one of their basic controls is unreliable.

There is nothing obscure in that. RichEdit control was made to use RTF so the ‘\r’ character is used for paragraph markers.

lol. RichEdit is NOT a basic control. It is a specialized one to display and edit RTF data and it is perfectly reliable when it is used as intended.


What is actually absurd is not knowing what a RichEdit is for and wanting to use it like a Multiline EDIT control. Simply explained, picture it as a WYSIWYG HTML editor, the control is intended to preserve the displayed page NOT the underlying HTML (binary text in this case)

It was an ABSURD desicion by Xojo to use the RichEdit, they should provide a REAL multiline “TextField” (based on the same EDIT native control) to avoid all the problems they caused using the RichEdit.

This is not what I described as obscure. Please read twice before immediately criticising.
The obscure thing is to remove one character because the previous one is already the same. That’s not because of RichEdit.

Yes, hide your face. It pleases me.

Xojo just has a TextArea control. It’s fairly logical for an user to expect to use it as an edit control since Xojo doesn’t provide a better control.

Probably, but I understand why currently, one would try to use the TextArea for multiline text editing.

And please, stop criticising people before you actually think. That’s just contemptuous.

No, the control does not remove characters if you use EndofLine.Macintosh. I know it is unpractical, but it is a valid workaround.

1 Like

Nice to know, thanks.

It probably should only replace on the way in, and not on the way out.

That would make it at least a little better. And not destroy any other cases.

for me its a bug

TextArea1.Text = "Some test" + EndOfLine.CRLF
TextArea1.Text = TextArea1.Text + EndOfLine.CRLF + "Some other text"

should be look same as
TextArea1.Text = "Some test" + EndOfLine.CRLF + EndOfLine.CRLF + "Some other text"
but it does not at Windows

Indeed it is a bug.

Seems related to this: String from TextArea: Line endings (EOL) - General - Xojo Programming Forum
@JulianS thanks for explaining what’s happening in the underlying control on Windows.
I noted a workaround in the other thread, which I just use in an extension method to retrieve text from textareas across platforms.