Carriage return displayed as string of question marks inside diamonds textarea

Please post your code.

1 Like

sCR = DefineEncoding(Chr(13), Encodings.UTF8)

Window_log.TextArea_log.AddText(“Hello, world!”)
Window_log.TextArea_log.AddText(sCR)

Xojo has a way of dealing with EndOfLine since the platforms have different means of doing so.

You may wish to review the EndOfLine function and the ReplaceLineEndings function.

1 Like

I did try EndOfLine, no difference. Will try ReplaceLineEndings now.
Thanks.

Try this instead:

sCR = EndOfLine

I am assuming addText is something like TextArea_log.Text = TextArea_log.Text + whatever.

Note that Chr(13) is endofLine.macOS.

EndOfLine.Windows is chr(13) + chr(10)

EndOfLine without the platform is the default for the platform under which the program executes.

2 Likes

Thanks, Michel. EndOfLine has the same result. Even with the correct platform, macOS; or default.
The output has a sequence of ?-in-diamond chars, not just one:

Hello, world!���������������������������������������������������������������������������������

Can you share a simple sample that people can download and reproduce your problem? You can use dropbox, google, microsoft or other share service.

1 Like

TextArea_log is a TextArea

Window_log.TextArea_log.AddText(“Hello, world!”)
Window_log.TextArea_log.AddText(EndOfLine.macOS)

Please try using TextArea1.Text = "Hello" + EndOfLine + "World"

It really should be that simple.

1 Like

@Tim_Parnell

I got the same google result as you and was posting but saw you beat me to it :laughing:

1 Like

This is why Windows can’t display your EndOfLine. EndOfLine.macOS is not an EndOfLine on Windows, as neither is just Chr(13).

You need to use the EndOfLine function as I described just moments ago.

TextArea1.Text = “Hello” + EndOfLine + “World”

I used “+” originally when I discovered this problem. So, it’s just the EndOfLine/CR that causes the sequence of these characters.

It’s the wrong end of line sequence that causes those display characters.

EndOfLine is a function that will pick the correct sequence depending on the platform. Specifying a type of EndOfLine defeats that and is why you are getting the invalid characters.

ReplaceLineEndings is used to turn line endings from an unknown source into something you expect.

2 Likes

you need to define or convert the encoding (only if it differs) but for the whole string:

Make sure all input strings you add to the textarea are utf-8 NOT only the chr(13) etc.
Your best will be to use EndOfLine.* (module) value, EndoOfLine without “.” is a function perhaps…
However it may be make sure you use UTF-8 on ALL strings, including what the user pasts that are added to the textarea.

1 Like

Not the problem here.

OP is specifying EndOfLine.macOS and seeing the diamond on Windows (see their post). Completely expected because EndOfLine.Windows is two bytes, not one.

If they use the EndOfLine function, as I have suggested multiple times they will get the correct sequence no matter what platform they are on or building for.

1 Like

EndOfLine.MacOS = The macOS line ending as of macOS 10.0, Chr(10).
Says xojo docs?

1 Like

You are right, @DerkJ. Indeed today endofile.macOS is chr(10). Thank you.

I am showing my age :wink:

2 Likes

What is the code in AddText() ?

1 Like

Hello all,

Thanks for all your help. I narrowed down the problem and it turned out that the text area string has many (about 12) concatenation operations ("+") later on and causes the problem.

Changing the "+"s into AddText solves the problem!

Thanks again!

1 Like

Hi Robert,

what you see is called the Replacement Character.

You will find more information about this character here:

Remember: you may found this character in your software because of other reasons.

Also, as you may already understand, you have to avoid concatenation because it also tooks time to execute and memory space. I do not talked about the Encoding that may be different in your text… in the end. (each string may have its own Encoding).

1 Like