This is in a Desktop app. I have a TextArea where a user can paste some text, usually several lines of text.
I need to break this text up into a string array of individual lines, so I use the following code to accommodate the different CR/LF combinations on MacOS and Windows :
var s() as String = TextArea1.Text.ReplaceAll(Chr(13), Chr(10)).ReplaceAll(Chr(10) + Chr(10), Chr(10)).Split(Chr(10))
This eliminates all CRs (ASCII 13) and ensures only LF’s (ASCII 10) at the end of lines on both OSes, and removes empty lines so that each element of the array has a nonempty string.
But a user has come to me with an issue where my code is failing. Somehow their EndOfLine character is Chr(11). I watched them type it and that’s what their keyboard is sending (Their OS is Win11).
Per ASCII charts, 11 is “vertical tab”, and I would have never thought to test for this. I can’t fathom the places that this would break my code over the years in other areas. ASCII 11 isn’t even given an EndOfLine constant in Xojo, so it never occurred to me to test for.
Does anyone know why a user’s keyboard would be using ASCII 11 for EndOfLine? Is this just a thing we need to be testing for all the time when dealing with multiline input? Are there any other EndOfLine characters to know about and test for?
Edit: I should mention that when the user types it, it looks like a regular EndOfLine. I had to write it to a file and examine it in a hex editor to find out what was going wrong.
23 posts - 5 participants