Created attachment 81764 [details]
Replication of bug 123385 on Windows 8.

Hi,

I was able to replicate the bug you described on Windows 8 x64 in 400m3 (build 9702). As line endings on Win8 are CR/LF as opposed to a single character (your description implies you are probably on a different platform- mac/linux?), I was not expecting to be able to replicate, but lo and behold, when using your test document, selecting all and clicking the macro button actually doubles up the CR/LFs. I've pasted the state of the document after macro execution into notepad++ so that the linefeed characters are visible. A screenshot of this is attached as 123385replication_win8.png

I've also verified that your workaround macro works as intended on Windows 8.

I tried to run your macro with the ascii characters 0 to 32 (to see if any other control codes were being messed up), and nothing but the line feeds were doubled.

This is a very headache-inducing bug, as having to craft such a workaround is lots of extra work for a novice programmer working on some office automation. This behavior is also not noted on the documentation page for this function: http://www.openoffice.org/api/docs/common/ref/com/sun/star/text/XTextRange.html#setString


Regards,

Casey Doran

Remember: Writer <> (simple) Texteditor!

An end of a paragraph is not represented by a character like Chr( 13 ) rather than as format entry like in HTML: <p>My text.</p>

Changing the given code to:

Option Explicit
Sub Main
 Dim doc As Object
 Dim source As Object
 Dim dest As Object
 Dim s As String
 Dim s1 As String
 Dim c As String
 Dim i As Integer
 doc = ThisComponent
 source = doc.CurrentSelection(0)
 s = source.GetString
 For i = 1 To Len( s )
   c = Mid( s, i, 1 )
   s1 = s1 & c & " : " & ASC( c ) & Chr( 10 )
 Next i
 dest = doc.Text.End
 dest.SetString( s )
End Sub

With this code you will see that a paragraph break is shown only as line feed Chr( 10 ). (The empty line is the representation of the line break ASC( Chr( 10 ))!)

If one select
end.</p><p>Next paragraph
source.getString() should return
"end." & Chr(13) & "Next paragraph"
and not
"end." & Chr(10) & "Next paragraph"

like at this time.

Running on Windows 7 I also get CR -> CR/LF, but running on Linux it's CR -> LF.  That's very unfortunate, because LF -> LF so that you can't tell what character is in the document and given that, our extension is broken.  The C++ code I am using for testing is

void testInsertString(Reference<XTextDocument> text_doc, const char* text) {
	OUString input = OUString::createFromAscii(text);
	Reference<XText> xText = text_doc->getText();
	Reference<XTextCursor> xTextCursor = xText->createTextCursor();
	Reference<XTextRange> xTextRange(xTextCursor, UNO_QUERY);
	xText->insertString(xTextRange, input, sal_True);
	OUString output = xTextRange->getString();
	if (input != output)
		std::cerr << "String mismatch!" << std::endl;
	xTextCursor->setString(OUString::createFromAscii(""));
}

testInsertString(text_doc, "\r");
testInsertString(text_doc, "\n");
testInsertString(text_doc, "\t");