https://bugs.documentfoundation.org/show_bug.cgi?id=153759
Buovjaga <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|24.2.5.2 release |7.4.5.1 release CC| |libreoffice-ux-advise@lists | |.freedesktop.org Keywords| |needsUXEval --- Comment #9 from Buovjaga <[email protected]> --- (In reply to milchreis from comment #8) > Microsoft Excel: > 1. Open new blank workbook. > 2. Enter the number '1' into cell G1. Cell G1 now has the value '1'. > 3. Enter the formula '=$G1' into cell D1. Cell D1 now has the value '1' same > as cell G1. > 4. Click on column D to mark whole column D, then enter key-combination > Ctrl+C to copy marked whole > column D. Note the interrupted lines moving around column D indicating that > it is copied. > 5. Left-click on column B, note how whole column B is marked, and select > "Home -> Cells -> Insert -> Insert Sheet Columns". > 6. Note how values '1' have shifted from cell D1 to cell E1 and from cell G1 > to cell H1 as they should. However, column D is no longer indicated with > moving interrupted lines to be copied, and so the LibreOffice Calc bug > cannot even happen on Microsoft Excel. The solution to the LibreOffice Calc > bug is to also take off the interrupted lines and so the copy of the column > D as soon as cells get shifted around. > 7. Note that column B is still marked. > 8. Enter key-combination Ctrl+V, but correctly nothing happens as nothing is > copied anymore. So, no wrong value/reference can be copied after the shift > of cells, which correctly forces the user to make a new copy. Ok, so your opinion is that the non-action would be correct, essentially that the clipboard would be cleared, if new columns or rows are inserted. It seems rather disruptive. I tested it again in office.com and indeed, the clipboard is cleared irrespective of the content in the column. Let's ask UX team. -- You are receiving this mail because: You are the assignee for the bug.
