Issue 112788 - Wrong position of text cursor when editing in a Calc cell
Summary: Wrong position of text cursor when editing in a Calc cell
Alias: None
Product: Calc
Classification: Application
Component: editing (show other issues)
Version: DEV300m83
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@sc
Keywords: regression
: 113493 113518 (view as issue list)
Depends on:
Reported: 2010-06-29 15:04 UTC by niklas.nebel
Modified: 2017-05-20 10:33 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

for reference (1.79 KB, patch)
2010-07-01 14:04 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description niklas.nebel 2010-06-29 15:04:26 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?
Comment 1 caolanm 2010-06-30 14:55:42 UTC
Yeah, I see it.
Comment 2 thomas.lange 2010-07-01 09:16:34 UTC
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
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.
Comment 3 caolanm 2010-07-01 12:18:15 UTC
Bah, I don't think this is going to work at all. e.g. mixed bold/italic etc.
Comment 4 thomas.lange 2010-07-01 13:18:27 UTC
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
Comment 5 thomas.lange 2010-07-01 13:23:54 UTC
Note (in reply my posting from 'Jul 1 08:16:34'): 
An unwanted side effect of patching
  ScInputHandler::SetRefScale  and
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%. :-(
Comment 6 niklas.nebel 2010-07-01 13:30:16 UTC
The width was different between editing and non-editing already before, see
issue 68556.
Comment 7 caolanm 2010-07-01 13:30:58 UTC
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.
Comment 8 thomas.lange 2010-07-01 13:48:41 UTC
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.
Comment 9 caolanm 2010-07-01 14:04:17 UTC
Created attachment 70337 [details]
for reference
Comment 10 caolanm 2010-07-01 14:07:14 UTC
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
Comment 11 thomas.lange 2010-07-01 14:21:21 UTC
Old code
    long nPosInPortion = pLine->GetCharPosArray().GetObject( nPos );

Fixed in CWS tl81.
Comment 12 thomas.lange 2010-07-05 08:15:48 UTC
Comment 13 stefan.baltzer 2010-07-14 14:31:25 UTC
Verified in CWS tl81
Comment 14 michael.ruess 2010-07-29 13:35:24 UTC
*** Issue 113518 has been marked as a duplicate of this issue. ***
Comment 15 niklas.nebel 2010-07-29 14:51:04 UTC
*** Issue 113493 has been marked as a duplicate of this issue. ***