Apache OpenOffice (AOO) Bugzilla – Issue 112788
Wrong position of text cursor when editing in a Calc cell
Last modified: 2017-05-20 10:33:46 UTC
Create a new Calc document, set the view zoom to 110%, put something like "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" into a cell. Edit the cell (in the cell, not the input line), move the cursor left from the end. The cursor position doesn't match the visible text. This is caused by the editeng.cursorpos.patch from issue 74188, integrated in m83. I'm not sure if the use of GetRefDevice is wrong or if there's another difference in how the EditView layouts its text. The wrong cursor positions look similar to the normal text output of the cell, when not editing. @cmc: Can you take a look?
Yeah, I see it.
The problem occurs only with Calc cells in edit mode. No problem with draw objects in sd or sw. When debugging the only notable difference is that with Calc edit cells the scaling of the MapMode is NOT 1:1 for x and y axis. For Calc edit cells it is set to the zoom factor of the view. In Calc there are two functions ScInputHandler::SetRefScale and ScInputHandler::UpdateRefDevice that curently set the MapMode scaling to the zoom factor. If I change those to constantly use 1:1 everything seems to be fine. Need to check with QA if anything gets broken by doing this.
Bah, I don't think this is going to work at all. e.g. mixed bold/italic etc.
HDU: I just saw the change that introduced the regression. Didn't debug into it but I have to say that an approach to calculate cursor positions from widths of individual text parts is doomed to fail in some situations. Better use OutputDevice::GetCaretPositions().
Note (in reply my posting from 'Jul 1 08:16:34'): An unwanted side effect of patching ScInputHandler::SetRefScale and ScInputHandler::UpdateRefDevice to use 1:1 scaling is that the width of the displayed text changes between edit mode and non edit mode if the zoom factor is not 100%. :-(
The width was different between editing and non-editing already before, see issue 68556.
Well, I reckon the best thing is to revert the original change for 3.3 anyway, as any fix will be too raw for primetime.
tl->cmc: Ok, I will undo the patch and restore the original code then. As discussed with SBA I will also reopen the original Bengali issue.
Created attachment 70337 [details] for reference
FWIW, this mighty hack which persists in the old pattern illustrates, and without any sc patch would have sort of "worked", but lets see if we can do it "right".
Old code long nPosInPortion = pLine->GetCharPosArray().GetObject( nPos ); restored. Fixed in CWS tl81.
.
Verified in CWS tl81
*** Issue 113518 has been marked as a duplicate of this issue. ***
*** Issue 113493 has been marked as a duplicate of this issue. ***