@lomacar:
What you are talking of as two lines
is actually two paragraphs
. The distinction between lines and paragraphs and the representastion of “new paragraph” in code was a mess in text processing by software from the beginning. (It’s still a mess, also in the heads of users.)
There never was a generally accepted single ASCII code for “new paragraph”. Some systems didn’t distinguish it from “new line” at all, others coded it by different combinations of (decimal) ASCII 10 (LF) and ASCII 13 (CR).
That was the time of strictly character oriented output devices where “carriage return” and “line feed” were very different things and the first option allone lead to overwriting the same line. Also VT existed! And HT is still in use.
In short: The way “new paragraph” is currently represented in the string property of a TextCursor (or ViewCursor) in living LibO documents is Chr(13) & Chr(10), at least on Win systems. (Hopefully on other systems, too, though the may use the reverse combination or Chr(13) allone on the OS level.) There is NO guarantee of any kind that this -however it is- will not be changed without notice. If you insist on splitting paragraphs in Basic based on the strings returned by cursors, don’t forget to remove trailing or prefixd Chr(10) from the array elements you get.
You may try myLines = Split(myString, Chr(13) & Chr(10))
.
(Edit 1 with respect to the comment below:)
TextCursor objects can enumerate the paragraphs they intersect with as objects. See example code:
Sub enumerateParagraphsForViewCursor()
theVC = ThisComponent.CurrentController.ViewCursor
theTC = theVC.Text.CreateTextCursorByRange(theVC)
theTCEnum = theTC.CreateEnumeration
Do While theTCEnum.HasMoreElements()
theEl = theTCEnum.NextElement
MsgBox(theEl.String & " : " & theEl.ParaStyleName)
Loop
End Sub