Apache OpenOffice (AOO) Bugzilla – Issue 17014
getTextAtIndex(LINE) returns wrong value
Last modified: 2004-01-27 17:18:47 UTC
In edit engine of Calc, Impress and Draw application getTextAtIndex(LINE) returns always (-1,-1) when cursor is at the end of text. This is wrong because an at-tool does not report a text when cursor is placed at its end and at-tool does not report a just written character. Output from logging of java_uno_accessbridge when cursor is at the end of a text: [text] Paragraph 4: getTextAtIndex(LINE,2) returns (-1,-1,) [text] Paragraph 4: getCaretPosition() returns 2 Output from logging of java_uno_accessbridge when cursor is in the text: [text] Paragraph 1: getTextAtIndex(LINE,11) returns (0,14,This is a text) [text] Paragraph 1: getCaretPosition() returns 11
.
Assuming that the API spec allows it, I would use the same methods here as within the AccessibleStaticTextBase::ImpCalcInternal() method (around line 388), namely, not only allow one past the end values, but also returning the last found instance for them. BTW, with which AT tool did you produce this bug? AFAIK, ZoomText never asks for lines.
It is Gnopernicus. This is a combined screen reader and Braille monitor on Gnome.
Agreed with TZ.
Okay, fixed as described. TextType::LINE now returns the last line, even for one- behind-the-last index values. While doing this, removed the special case for ::LINE from getText*Index() methods. The overridden implGetLineBounds() for the OCommonAccessibleTextHelper was already there (though buggy implemented), only not reached because of the early interception of the ::LINE case in the named methods. Along the lines, added some more consts, adapted assert strings to the actual method names.
Please verify.
Ralf -> Thorsten: I verified the bug in thb07. It still occurs. When positioning curser at the end of text getTextAtIndex() still returns (-1,-1) and at-tool does not report on text.
Okay, hope I've found it now. Problem was that a helper class (OCommonAccessibleText) was a little bit sensitive to empty ranges. And I returned (textLength,textLength) for start/end index for the described case. Said helper then mapped that back to (-1,-1).
Works fine now.