Easy One? Number of Lines in a Text Area

Targets Windows
1

Working in Xojo 2025 R1.1

I have a LINEFEED delimited “text file” (downloaded from a LINUX system) – I checked in a hex editor…it only contains LINEFEEDS no carriage returns. I created a FolderItem and TextInputStream as you would expect. Have a text area called taSource and I performed the following. taSource.Text = t.ReadAll – the text area populated perfectly and quickly with the source data. I want to know how many LINES are in the text area. So I did this:

SrcLInes = CountFields(taSource.Text,EndOfLine.LF)

This works perfectly on MacOS, But doesn’t fly on Windows the answer is always “1”
I’m guessing it has something to do with the TEXT area containing (Styled) TEXT versus STRING and perhaps if I had read the data into a STRING I could do the CountFields? Something about the way Windows handles a Text Area?

Seems like a TEXT area which can locate a selected Line Number sequence ought to have a Number of Lines property.

2

Please use String.ReplaceLineEndings to normalize the end of line characters.

e.g.

Var s As String
s = someString.ReplaceLineEndings(EndOfLine)

so you make sure it has the one you expect.

3

I tried this and it didn’t fly on a Windows build either.

  // Read all the contents into a TextArea control
  taSource.Text = t.ReadAll.ReplaceLineEndings(EndofLine)
  
  // Close the file stream when done
  t.Close
  SrcLines = CountFields(taSource.Text, EndOfLine)
  MessageBox("Number of Source Lines -->"+str(SrcLines))

Tried counting EndOfLine.Windows etc. It’s strange…I just can’;e seem to count the lines in a Textbox in a Windows Build. I tried setting the t.Encoding to ASCII instead of UTF8 –no help. I guess I’ll try reading the textInput Stream into a string… at least that’s easier to see in the debugger.

4

I knew what to expect since I know where the source file is coming from… the trick was reading the text input stream into a string variable… performing the field count on the string variable…and then assigning the Text Property of the textArea = the String. I guess you just can’t count the lines in a TEXT area in Windows the same way you can on MacOS – I’m guessing the “structure” of a Text Area is… different. I wonder what would happen if I tried to count another character like “a” if that would work. I figured even if a line was terminated with CRLF …. counting the LF characters would still give the correct answer (for my purposes)

5

putting text in a textarea may change the line endings.

Before you use CountFields or NthField or Split, better always normalize it.
If there is nothing to do, the function will just return the same string.

6

If memory serves, TextArea always uses Chr(13) internally regardless of everything else.

7

On Windows you’ll get the Windows EOL out of a TextArea (unless the user pasted in an already formatted line ending). That’s why it’s recommended to normalize before splitting.

For those wondering, we do so with String.ReplaceLineEndings

1 Like
8

Yes, it makes sense to do your work on the string before putting it into the textarea. I’m curious about what its encoding is before any modifications. I wouldn’t be altogether surprised if it were nil, meaning that you would use DefineEncoding instead of trying to convert it as you’d mentioned.