Is there any way to know or detect linebreaks of text in a textarea.
Just make them be the ones you want
Use something like
dim s as string = ReplaceLineEndings( textArea1.text , EndOfLine)
You mean where a line breaks, or where there is an End Of Line characters (Chr(10) or Chr(13)) entered?
linebreaks does not put either on the canvas but put the Condense property DrawStrin (Condense = true)
Part I paragraphs of text.
I have this line to send the text:
Pages (me.CurrentPageID).Graphics.DrawString (TextArea1.Text, left, CurrentHeight me.MarginTop + + Pages (me.CurrentPageID). Graphics.TextAscent, me.MaxWidth, True)
can know how line breaks in the text loaded into a textarea?
Oh you want to know WHERE a long line is wrapped when you put it in the text area ?
show text in TextArea:
[quote]Either linebreaks does not put on the canvas but put the property DrawStrin Compact (Compact = true)
Part I paragraphs of text.
I have this line to send the text[/quote]
I want to know is if I can capture in a variable number of line breaks, which in the example would be two line breaks.
After struggling with a TextArea and end of lines, I’ve seen this conversation in the blog that reminded me about ReplaceLineEndings.
It solved my problem, but I can not understand what is Xojo idea after this weirdness:
- create a single window application with a TextArea control.
- in the Open event add this code:
[code]for i As Integer = 1 to 10
TextArea1.Text = TextArea1.Text + Str(i) + EndOfLine
Dim t() As String
t = TextArea1.Text.Split(EndOfLine)
Although I’ve used the same “EndOfLine” just three lines of code away, its value is different and t has only one dimension!!!
Is it because of any type of back compatibility?
Anyway, I think that this is not a good behaviour, although I can use ReplaceLineEndings
I believe that Xojo uses the same EOL character in TextArea across platforms, and it may be different than your system EOL. It does that translation when you enter text into the field, so what you get out of it may not be what you put in because the EOL character has been converted. I think that’s what you’re seeing.
Mac and Windows it is chr(13) inside the TextArea.
Yes, Michel you are right.
It seems EOL is chr(13) in TextAerea no matter what is your platform.
Out of it, it depends on the platform.
In Strings it appears to be Chr(10) for OS X and Linux and Chr(13) for Windows (not Chr(13)+Chr(10)).
Did this change is recent years?
I just examined the Text property of a Textarea under macOS, and it was CHR(10)
From my tests on macOS and Linux, whatever EndOfLine you use the TextArea will not change it. You can test this with a simple:
TextArea1.Text = EndOfLine.UNIX
TextArea1.Text = EndOfLine.Macintosh
TextArea1.Text = EndOfLine.Windows
and check the TextArea Text contents on Binary Tab, you will get 0A, 0D and 0D0A.
On Windows, whatever EndOfLine you use, it is changed to EndOfLine.Macintosh, chr(13). The same code in Windows will say (in the Binary Tab), 0D, 0D and 0D.
There is a Verified bug report about this. Don’t you want to try the new Feedback 2018r1?
I found this to be true recently. It’s CHR(10).
This doesn’t work for me.
My data is stored in mysql. I can view the line endings in a varchar(1024) field with charset of latin1/latin_swedish_ci (mysql 8.0.21)
I can enter text into the text area control and it takes line breaks, as expected.
When I load this from the database (after save/reload) into the text area control - it looks like this
“This is line 1�Line 2�Line 3�”
When I copy and paste the above into BBEdit and turn on invisibles, it looks the same except the “?” is upside down (I can’t copy and paste that into this editor)
It does work in the debug log:
System.DebugLog( Client.Description ) outputs:
“This is line 1
Is there some property of the text area control I need to set?
in 2020, you still use antics charset ?
Why don’t you go ahead and use UTF8 ?