Problem with TextInputStream.ReadAll

The string obtained from TextInputStream.ReadAll somehow prevents the display of appended text in a TextArea. It also prevents XojoScript.Source to not getting the completed ScriptCode.

If you want you can test this yourself with

[code] dim f as folderitem
dim input as TextInputStream
dim s as string

if f<>nil then

input = f.OpenAsTextFile
s =  input.ReadAll

s = s + TextArea2.text
TextArea1.text = s

end if
The confusing thing is that when interrogating the length of the text from input.ReadAll and from TextArea2.text and compare it to the resulting length of the string s you would expect input.ReadAll + TextArea2.text to be displayed. Note that s = TextArea2.text +s does show all text. See feedback://showreport?report_id=41442

End of Line? Encodings? Null byte? Any of those could explain what you’re seeing. Display in a text area can be corrupted in many ways.

Edit: looking at your feedback case, your text file contains a Null byte. That is the problem.

differing encodings in the two strings prior to appending?

I agree. It’s probably a chr(0) at the end of the text.

That appeared to be not relevant after testing earlier. When the stream is assigned to a string it gets the UTF-8 encoding as can be seen in the debugger. Workarounds are to put the stream into an editor and then assign TextArea.Text to a string, or you do s = s.left(s.len-1), the get rid of the extra null byte. Note, on osx there is not a problem. Also, in the past with earlier versions of xojo, it worked fine. Perhaps it is a specific Windows 10 issue, don’t know. I consider it a bug given the above. Others believe it is not a bug.

The concatenated string is also UTF8, the length is also representative of the concatenated string, yet the extra null byte makes it not cross-platform aware.

I’m seeing the same thing on Windows 7 and on older versions of Xojo. The problem is that even though the string is marked with a UTF8 encoding (the default), the string itself is not valid UTF8. A string in Xojo can contain any arbitrary byte values, in addition to valid text, and Xojo can deal with the null handily, but any OS-provided functions will see the null byte as a termination character.