Bug 82599 - Insert and overwrite mode reversed in cell while editing on the Calc Formula bar
Summary: Insert and overwrite mode reversed in cell while editing on the Calc Formula bar
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Calc-Formula-Bar
  Show dependency treegraph
 
Reported: 2014-08-14 07:06 UTC by domenik.hein
Modified: 2018-08-20 07:54 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
A picture that proofs the different output of the same cell (6.19 KB, image/png)
2014-08-14 07:06 UTC, domenik.hein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description domenik.hein 2014-08-14 07:06:04 UTC
Created attachment 104603 [details]
A picture that proofs the different output of the same cell

When I'm using the isnert key toggled on my keyboard and double clicking a cell and editing the text in the formular line the behaving isn't as expected.

Steps to reproduce:
1. Doubleclicking a Cell and put the cursor on the end of the line in the formular editor whiles the insert keyboard function is toggled on.

2. now moving with the arrow keys some letters before the end. So that the black block appears. (When the insert key gets activated while the formula editor line has already focus it "MOSTLY" works)

3. Now write something.

Current behavior:
The text in the formular editor line gets replaced as its the intended behaving of the toggled insert function.
But the line in the table which you can vie at the same time doesn't. It merges it instead. And also if you confirm the line in the formula editor. the letters in the cell differ from those you confirmed (made me a big effort to review my work and correct this)


Expected behavior:

The value in the cell should be also replaced, same as the one in the formula editor. Or at least if it is the intention to not support the insert key, dont make the via enter confirmed value be different from the one written in to the cell by using the isnert key.
              
Operating System: Windows 7
Version: 4.3.0.4 release
Comment 1 Jacques Guilleron 2014-08-22 14:08:01 UTC
Hi domenik,

I reproduce this behaviour too with LO 4.3.0.4, except the first time after opening where I have the correct behaviour (all versions). The second time and the others, even if caracters are replaced in the editing windwow, caracters after inserting point are kept in the cell.
The same with: 
LO 4.4.0.0.alpha0+
Build ID: eddd7646d672ea9b0561dacb09da224d098e531e
TinderBox: Win-x86@39, Branch:master, Time: 2014-07-18_06:42:50
LO  4.2.7.0.0+
Build ID: 92216be6ce13990b8ea6b6264c656d2bc1746401
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-07-14_16:21:42
LO 4.2.2.1
LO 3.6.7.2
LO 3.5.7.2
LO 3.5.3.2
So I assume this has never be seen before.
Windows 7 Home Premium.

Set Status to NEW.

Thanks for your report,

Jacques
Comment 2 domenik.hein 2014-11-12 07:35:52 UTC
I'm sorry if I'm pushing a bug that is already known and handled /fixed under another ID, or pushing at all is unwellcome.

But reading of the 4.3.4 RC And still not noticing any attention for this bug made me feel this to be necessary.

As this bug is tricky, interupting workflow. And if you don't know of it and expect different things to be saved as they have been saved. There could be many cases where it even could harm statistical data and lead into harmfull results.

So I think this should get more attention.
Comment 3 tommy27 2016-04-16 07:26:51 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2017-05-22 13:23:10 UTC Comment hidden (obsolete)
Comment 5 Timur 2018-08-20 07:54:49 UTC
Looks not resolved with Bug 119128. Repro 6.2+.
Depending on how you edit, could be seen from subsequent edits.