Problem description: Impossible to perform a drag & drop of entire row/column, whether moving, copying (+ctrl) or switching (+alt) Steps to reproduce: 1. Select entire column or row 2. Drag & drop the row / column to be inserted into the new position. If you want to copy or switch simultaneously pressing the ctrl or alt button To be less confusing in the descriptions I only use rows, although the same goes for columns, nor will I mention the +ctrl and +alt options although they are affected the same way Current behavior: Calc only moves part of the row, starting at the first not empty cell to the last not empty cell, leaving the rest unchanged. If the first not empty cell is not the first of the row it will be put in the first cell of the new position. e.g. I want to move row 10 to row 2. Row 10 has data in the cells D10, E10 & G10. When I move the entire row 10 to row 2, it results in only moving the cells (D10..G10) to (A2..D2) leaving the rest of row 2 untouched. Expected behavior: If the entire row is selected, the entire row should be moved Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20100101 Firefox/10.0
Although this looks similar to bug 35570 it is not, earlier versions didn't have the bug 46230, there I could move the rows and columns the way they should.
I believe "Bug 47096 - EDITING: Alt + Drag and Drop for complete rows impossible in particular documents" has thame roots. @Helping Hand: I believe I saw your problem during my tests for a.m. bug, but currently I can't reproduce you problem. Can you please attach a sample document and a document related step by step instruction? Can yo confirm Bug 47096? What was the last version where that worked for you?
[Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) and sample document for "Bug 47096 - EDITING: Alt + Drag and Drop for complete rows impossible in particular documents" <https://bugs.freedesktop.org/attachment.cgi?id=58183> Steps how to reproduce: 1. Download / Open a.m. sample document 2. Click on row header 67, move moue pointer with pushed left mouxe button to row header 69, so that rows 37-69 will be selected 3. Click into A67, move mouse pointer upwards with pushed left mouse button to drag and drop 3 lines Expected: complete rows moved Actual: only Cells A64:A69 will be moved. And I succeeded to create a much more simple sample document, I will attach with next step. Together with Bug 47096 that's really annoying. @Kohei: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Created attachment 58337 [details] Simple Sample To reproduce Bug please proceed as per Comment 2
Works fine with parallel installation of MinGW Master "LibO-dev 3.5.0 Beta 1 – WIN7 Home Premium (64bit) English UI (Build ID: 8935521-b204871-3e50423-4c1bcb5) (daily/Win-x86@7-MinGW/master/2011-12-13_03.17.52)", [Reproducible] with Parallel Dev-Installation of "LibreOffice 3.5.0 Beta3- WIN7 Home Premium (64bit) German UI [Build-ID: e40af8c-10029e3-615e522-88673a2-727f724] I am really really sure that this one and Bug 47096 have the same roots (or Bug 47096 is a DUP)
I will look into this one. This is most likely a regression introduced by Muthu's and my work on pasting for external applications.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a26fe4a39b6f3b2af269b801340c32c28806250 only shrink to used area in text export, fdo#46230, related n#677811
I hope I finally fixed all problems introduced by the original fix for n#677811. We now only shrink the area to the used area when we use paste as text and not for every case.
*** Bug 45868 has been marked as a duplicate of this bug. ***
Which build
What release will be the first fixed?
*** Bug 47096 has been marked as a duplicate of this bug. ***
*** Bug 47017 has been marked as a duplicate of this bug. ***
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ee518863337fba9bce019e05e24f527617a4321 also shrink used area for HTML in some cases, fdo#46230, n#677811
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=39228c6d2419636be04ee4a320a7c0ca08276f37&g=libreoffice-3-5 also shrink used area for HTML in some cases, fdo#46230, n#677811 It will be available in LibreOffice 3.5.2.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a58d877fd576bacd738972a78c8310d4eccb0daa&g=libreoffice-3-5 only shrink to used area in text export, fdo#46230, related n#677811 It will be available in LibreOffice 3.5.2.
*** Bug 48006 has been marked as a duplicate of this bug. ***
*** Bug 48128 has been marked as a duplicate of this bug. ***
I use LibO Calc 3.5.4.2 on Ubuntu 12.04 64-bit and I'd say the issue is still present.
@rpr.nospam: Can you provide a spreadsheet?
NOT reproducible with "LibreOffice 3.5.5.2 English UI/ German Locale [Build-ID: 24b32b4-b87ec2e-85c8e98-87a4e20-9a1b8c1] on German WIN7 Home Premium (64bit) @rpr.nospam@gmail.com <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>!
Sorry, it's my fault. I didn't realize that the mouse pointer must be placed inside the range of selected cells, and not at the column/row header, for drag and drop to work. This should be mentioned somewhere in the Help (e.g. under Moving Cells by Drag-and-Drop).
@rpr.nospam@gmail.com Thank you for quick feedback!