Please post your code.
sCR = DefineEncoding(Chr(13), Encodings.UTF8)
Xojo has a way of dealing with EndOfLine since the platforms have different means of doing so.
I did try EndOfLine, no difference. Will try ReplaceLineEndings now.
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.
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:
Can you share a simple sample that people can download and reproduce your problem? You can use dropbox, google, microsoft or other share service.
TextArea_log is a TextArea
Please try using
TextArea1.Text = "Hello" + EndOfLine + "World"
It really should be that simple.
I got the same google result as you and was posting but saw you beat me to it
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.
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.
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.
EndOfLine.MacOS = The macOS line ending as of macOS 10.0, Chr(10).
Says xojo docs?
You are right, @DerkJ. Indeed today endofile.macOS is chr(10). Thank you.
I am showing my age
What is the code in AddText() ?
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!
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).