Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Wrong position of text cursor when editing in a Calc cell | ||||||
---|---|---|---|---|---|---|---|
Product: | Calc | Reporter: | niklas.nebel | ||||
Component: | editing | Assignee: | stefan.baltzer | ||||
Status: | CLOSED FIXED | QA Contact: | issues@sc <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | caolanm, hdu, issues | ||||
Version: | DEV300m83 | Keywords: | regression | ||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
niklas.nebel
2010-06-29 15:04:26 UTC
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. *** |