TextArea Issue

Is there issue withTextArea in Linux? I have a small app where I have two textarea controls. I Get text from one, manipulate and write it to the other. That part works fine. Now if I try to manipulate the text from the second one and rewrite it, I just get a blank box. This works perfectly in Windows and MacOS.

Now in Linux, I can take the manipulated text and write it to a table or a plain text field fine, just not the textarea.

Anyone seen anything like this where it works elsewhere but not Linux?

Is the text color white or white background for example?
Are you able to copy the data back from the textarea into a file, e.g. is the data actually there?

i would check len of .Text and what StyledText.RTFData outputs.

No, the text is in a string before I write to that box. I can write that string to a label, message box and a regular text box without issue. When I write it to the TextArea, the box remains empty.

This is only on Linux. Works fine in Windows and MacOS

I will look at that. However, since the problem only occurs in Linux, I don’t think it’s a code issue in this case.

can you show this method?

When I’m back at my computer, yes.

1 Like

Did you read?


Var s as string = "test"
Textarrea1.text = s
Var s2 as string = textarea1.text

What is the value of s2 in the debugger?

Yes I read. I have tried a number of tests like this. Keep in mind, this is working just fine in Windows and MacOS. I’m building on the Mac and all looks good. Linux is the issue. I’ve also used MessagBox to view the variables at various parts of the routine, all looks good. The issue is within the TextArea on Linux as I can print the manipulated text in Linux to other controls without issue.

Sounds like a bug, make an Fb report with an example project or video.

Might this bug be related?:
65452 - In Pi, shrink a TextArea’s Height and it will still receive click within the default Height 100.
Status: Open Rank: 572nd

I agree. I will

I don’t see how it’s related to the PI Shrink issue.

Not knowing how you address the target TextArea I was thinking maybe
you point an click. Maybe you have resized the TextAreas so that,
because of the bug, the destination becomes wrong.
Just a hunch and maybe a long shot, but yes, there is an issue with TextArea in Linux.

If you mean resizes the TextArea at runtime, that’s not happening. In fact when I type text into the first box and click the button that manipulates it, the code copies the updated string directly to the TextArea in question. i.e.


None of the above requires the cursor to go anywhere near the problem TextArea.

I’ve also tried writing to it in code with a new string after the problem occurs and then it works.

I have submitted a bug report.

I also just noticed that the bug you mentioned was for the PI, I’m not testing on that. In addition, the controls are fixed, so there is no way I can resize them at run time even If I wanted to. And no, I’m not doing it in code. I’m pretty certain the 65452 bug is not related. Of course it does indicate issues with the TextArea in Linux. It will be interesting to see what I hear back on the bug report I filed.


Thanks for your suggestions. I just wanted to share what the issue was. A problem in my code was producing an extra character at the end, 0. I’m not sure why Windows and Mac didn’t have an issue with this but correcting the code fixed the issue. Thanks to XoJo support for a quick response. It does seem like there should be some consistency here in that none of the 3 OSs should have accepted it, or all 3 should have.

Anyway, problem solved, lesson learned.