TextArea1.Text returns text that is inside the
TextArea1. As far as I know
TextArea automatically sets EndOfLine at all line endings on Windows 10, right?
In my case, this is not happening, or it could be that I’m doing something wrong. I want to get all the text from
TextArea1 with line breaks after each line, and then use it as a parameter which will then be passed to a Python script.
Shell1.Execute("python3 main.py " + TextArea1.Text)
The Python script will then use Selenium framework to browse my website and paste the text from
TextArea1 to a
<textarea> on my website.
Right now, I don’t see line breaks when I’m using only
TextArea1.Text. Unfortunately, the whole text is just one line.
Then how would I be able to determine whether there is a line break or not?
Is there a way to read a
TextArea line by line?
Maybe I could use an event to determine if I pressed the “Enter” key and then insert a line break or something like that. But that wouldn’t work if I pasted text inside the
You’ll probably want to replace your line endings http://documentation.xojo.com/api/data_types/string.html#string-replaceLineEndings with unix line endings before sending your data.
Shell1.Execute("python3 main.py " + TextArea1.Text.ReplaceLineEndings(EndOfLine.UNIX))
If you press “Enter” then you insert a “Endofline”.
But there is not an automatically adding of “Endofline” when a line is broken because his length is bigger than the width of the textarea.
It was what I understand with your first post.
Then it will just take the first line to paste it in the
<textarea> on my website. All other written lines from
TextArea1 are missing.
@Eric_Pousse Then you got me wrong. I want to have
Text.EndOfLine each time I press enter inside the
I solved it with another step. I save the contents of
TextArea1 to a text file and pass the
ShellPath of the text file to the Python script. Inside the Python script, I read the text file.
For posterity, on the line endings issue, there is a gotcha: if you type multiple lines of text in a
textarea, on the Mac you’ll see the lines end in &h0A, the correct line ending for Macs. On Windows, however, they end in &h0D only… so if your code was expecting the typical line ending for Windows, you’re in trouble. I don’t know if this is a bug or not – &h0D line endings haven’t been around since classic MacOS…
The fix I use that is crossplatform is
myText = myText.ReplaceLineEndings(EndOfLine) –
ReplaceLineEndings finds any valid ending (including just the &h0D) and replaces with the local line ending.
And, ironically, I just got bit by this on Windows today. Even when you save to a file, as Alex did, it still will write the lines with &h0D. If your subsequent processing happens to recognize and convert this when you reload the file, it will “fix” the problem. In my case, I allow a user to write markup files in a textarea, which are then saved and processed by an appropriate external tool via the shell. For the previous tool, it apparently didn’t have a problem with the &h0D line endings, so no problem, I added a new tool, and it didn’t handle the endings on Windows. Adding the fix I listed above (which I should have done in the first place…) resolved the issue.
@Greg_O_Lone… is this the expected behavior of a TextArea on Windows, or should this be filed as a bug? (Looked in Feedback and can’t find one for this)