Apache OpenOffice (AOO) Bugzilla – Issue 13645
moving rows and columns in a table (don't overwrite but move target cells)
Last modified: 2016-04-27 16:33:09 UTC
If I select a row in a table and drag it to another place in the table, the original row that I drop it on is deleted. I think that in most cases the desired behaviour would be that the row is inserted in its new place rather than that it replaces another row. It may be possible to do this in some way but I could not find how in the help file.
There is a similar issue for Cacl : http://www.openoffice.org/issues/show_bug.cgi?id=14007
I concur with Simon - while I can see that sometimes you may want to overlay, it is better to insert. This matches word-processor behaviour - if you move paragraphs, you don't delete what follows. Also I find moving to insert is far more common than moving to overlay. Or is an alternatively to be able to 'Insert Rows/Columns from Clipboard' like MS Office?
SBA: Reassigned to Bettina from the User Experience team for consideration.
confirmed
This issue is also true for other OS like Linux. Hope it makes it at least into 2.0. At the moment move of rows and columns is nearly impossible. After delete of a column, the width of the column right to the deleted column is increased by the width of the deleted one. Thus there is no free width to insert a new column at the target position. Or do I miss a trick, which allows a user friendly move of row/column?
When is this issue going to be handled? It's a very bad restriction in table handling in comparison with MS WORD. Each editing of the order of table columns is very difficult at the moment.
Given that Tools/Sort can re-order whole table rows it seems the underlying document model must support at least the moving of rows up and down. It is an easy and much used feature in other WP's: MS Word: Ctrl-Alt up/down, Lotus WordPro: Alt up/down (move row) left/right (move col) I'd love to see OOo catch up with this one. Peter
*** Issue 17414 has been marked as a duplicate of this issue. ***
*** Issue 18195 has been marked as a duplicate of this issue. ***
setting keywords, reassigning, enhancing summary related issue for calc: issue 21280 (see also issue 14007) related issue for writer: issue 39405
Is there any updates on this issue? It's still present in 680m91. I agree with the enhancement because a drag and drop is a move, like a cut and paste. Doing cut and paste with the rows works correctly. I can reproduce the apparently-same bug it in another context: 1. I create a table, say, 3 columns, 6 rows. 2. Put data in row 3, 4 and 5. (1, 2 and 6 remain empty). 3. Select rows 3, 4 and 5. 4. Drag them to row 1. Writer moves 3 and 4 to row 1. Row 5 is deleted. Although in the original bug report this can clearly be interpreted as "replacement", this is not exactly the case: looks like Writer first copies the info and THEN it removes the "extra" (why?) row. Can the entire algorithm be simply wrong.
I agree, especially to peterthevicar (10/2/2004): It works yet in older versions of MS Word, and the most intuitive and comfortable way I've seen so far is in Lotus WordPro, where you can drag'n drop rows and columns to insert them *between* others. I would like to see this in Calc, too. (Cloph 12/26/2004, issue 21280, 14007) Deleting the old columns/rows is neither expected by novice users (intuition...) would expect nor very fluid in working, since you have more steps to do.
I suggest to make following options to insert a cell, column or row: 1) copy (duplicates -content- of originating element/s) 2) move (moves the element in a cyclic way) 3) insert (inserts a new element -> creates a new column or row or splits the target cell and inserts) 4) swap (swaps the content of target and originating selection) The standard choice should be move, since it does not alter the tables structure, nor is the content lost. Especially the move functions should be associated with the delimiter <ctrl> and the cursor keys. So one can select with the keypad via <shift> and move the region via <ctrl>.
Hello madbop, fine idea with that much options. I agree that "Move" should be the default way for the mouse. My questions: a) How to handle that 4 different options comfortably - and comprehensible?? b) What do you mean with "cyclic moving"? Inserting the moved row/column between two other and pushing the below/right one further? c) How to use "CTRL" for moving? With the *keyboard* like selected objects in presentations? Or with the *mouse*? At least in Windows Explorer-style programs, pressing CTRL while dragging a selected object by mouse copies it (a + sign at the mouse cursor) instead of moving (take Shift, not Ctrl). Regards.
Agree
Hello, I'm wondering, why this very nice feature of MS Office is not implemented since four years. Is there meanwhile another cool way of moving rows and columns in a writer table? Otherwise what are other users doing, when they want to reorder columns and rows of a table inside a writer document. Is there any hope, that this feature will ever be implemented?
I also need this feature. It's a real matter when reordering a table... now I've to: insert a new row, move the row with text (only the text is moved) on the new empty row, delete the old row (now empty) Sometimes if I have a lot of row to reorder, I save the file in .doc and I use msword to do this quickly. Other issues related to the table are 37809 Copy-and-insert for writer cells/columns/rows 39405 delete/cut also table, not only contents
Hello, any news on this feature? The equivalent in Calc has been fixed for 2.4: http://www.openoffice.org/issues/show_bug.cgi?id=7180 Might that ease a Writer solution? What about accepting it for a certain target milestone?
*** Issue 85628 has been marked as a duplicate of this issue. ***
This is a very useful feature that I use quite often for reorganizing spreadsheets after initially creating the. There are work-arounds but why not add it. - mjr
Please update the version to at least 3.0.0
As a new OOo user, this is something that is really putting me off using Writer. Reorganising a table should not require multiple mouse clicks - it should be possible with simple drag and drop, as in MS Office.
This has been a problem that I've complained about since version 1. It is now version 3. Is this ever going to be resolved? Do OOo developers read this? My primary use with OOo involves moving table rows around constantly. This issue is such a time waster and source of frustration for me. I NEED to have the insert functionality applied to row moves, like just about every other word processor I've ever used has. Otherwise, I am extremely happy with OOo. I just can't recommend it as highly to others when simple features like this go overlooked.
after talking to devs: change target to 3.x this means that the issue is more on the radar ... nothing more. pls note that also the UX team must be involved to create the specs.
+
I realize that the order of rows in a table do not matter to a database, but they do matter to the person trying to organize information in a meaningful way: e.g steps to creating a swap listing, where the steps are ordered for the user. Hope that makes sense. :-)
This definitely needs to be implemented. The fact is that many people use tables with complex formatting. To have to not only cut, insert, and paste, but then also to re-establish the formatting is a major imposition on the user.
Oh, I'm very disappointed. I assumed moving rows in OO would be as easy as moving lines of text. But now that I've discovered this issue has been reported first 7 years ago, I won't hold my breath for a solution.
Shocking, isn't it. The problem is that our human nature is to take on a job, but then get tired of it too quickly and never finish it. Such appears to be the case with tables here. The sum total of the requirements to include them, as ready to use in an application, remain unfulfilled. Drag and drop, functional cut and paste, select to insert or move to a specific spot; none of the options seem to work properly or at all. I decided to select and cut a row. All I got was the internal data, and I couldn't find how to insert it. So I created a new row where I wanted it, and then pasted into it. Unfortunately, I didn't get the stuff I had cut. I got something from somewhere else. Very dangerous behavior indeed. Tables are evidently still in the Alpha stage in Writer. Wouldn't it be better to let people know that this is the case with a release version without tables, and an alpha version with them? That would make more sense to me. Thanks.
Just to add my comment. This would greatly ease setting up and editing small tables (almost enough to drive me back to the alternative word processor): <ctl><alt><up arrow> should swap the current row with the row above (keeping the cursor in the current row so that repeated presses continue 'moving' the selected row upwards. <ctl><alt><down arrow> should swap the current row with the row below in an analagous manner.
Created attachment 76947 [details] Test case: Rose Dewar's resume template I am providing a test case. Of the four resume templates that come installed with LibreOffice, the one by Rose Dewar (Resume 4) is closest to what I need. However, my university recommends that the education section come before professional experience. Dewar's template is based on a table with invisible borders, so it is not a simple matter at all of cutting and pasting the text. Nor can I use the Navigator for this, since the section headings are table contents. What frustrates me most about this is that it has taken more than seven years to fix this.
Comment on attachment 76947 [details] Test case: Rose Dewar's resume template Frank is the only person I know whom I can flag attachments to.
I managed to flag grichter as well. I figure that since this issue is more than seven years old, I need the assurance that at least two developers have been given a case in point.
Comment on attachment 76947 [details] Test case: Rose Dewar's resume template removing the review request. Sorry Stuart, neither were I a Writer developer when I worked at OOo, nor am I involved with OOo at the moment, nor is an attachment's review flag intended for this purpose - it's maily for reviewing of patches.
(In reply to comment #34) > Comment on attachment 76947 [details] > Test case: Rose Dewar's resume template > > removing the review request. Sorry Stuart, neither were I a Writer developer > when I worked at OOo, nor am I involved with OOo at the moment, nor is an > attachment's review flag intended for this purpose - it's maily for reviewing > of patches. Do you know any developers who are or might still be working actively at OOo? How can I make sure that a developer sees this thread? I should think that a macro should do as a patch, if anybody has the time and the energy to learn OOo Basic. I cannot learn it at the moment.
+ I'm working with spreadsheets 10 hours a day on a regular basis and the lack of possibility of moving selected lines quickly and without the need of manually deleting empty spaces after inserting them into their new places causes wasting a lot of time which keeps me from using Calc - even if I'd like to very much.
I agree with the original issue, it would be nice that moving a column changes the place of that column in the table and not delete the contents of the target. Moreover, it would be consistent with the behaviour of Calc.