There is a similar issue for writer <a
href='http://www.openoffice.org/issues/show_bug.cgi?id=13645'> #13645
</a>.

Hi Bettina,

1 4 U

Peter
-------
@Andree: Could it be we know each other from our years of study?

There is no resource to get that implemented in OO.o 2.0. I targeted it to OO.o
later.

enhanced summary, set keywords and reassigned issue according to RFE process


These are the steps that need to be performed in Excel:

1.) Select the column or row that should be moved.
2.) Click Cut. 
3.) Select a column or row below or to the right of where you want to move the
selection. 
4.) In the Insert menu select Cut Cells. 

This issue depends on issue 21280

As issue 13645 for Writer, at this point OOCalc is less comfortable and
intuitive than others, especially Lotus 1-2-3 where the mouse drag'n drop is yet
more obvious than in Excel:
It would be great to be able to (and understand on the GUI) move rows/columns
and insert them between others.

This issue, and that which it depends on (21280) both still have the Target
milestone OOo Later.

This was done in 2004, a long time ago now.

As Andree points out, this is a frustration when migrating from Excel to OOo.

Also, the steps outlined by dancer are not what is needed, rather drag and
drop/INSERT by using the Shift key, NOT cut and paste/insert.

Can this issue be reviewed so that a definite Target milestone is set?

Hi,
yes, I agree to 8daysaweek: It would be fine to have an idea about the timetable.

8daysaweek, thanks for the hint with the Shift in Excel for inserting moved
columns/rows instead of overwriting the target.
As mentioned, in Lotus 1-2-3 inserting (instead of overwriting) is the default
when dropping, without pressing an extra key. 
To me, this is more intuitive than Excel, where I (at best) get a warning that
the target will be overwritten.  In the writer Lotus Word Pro, inserting is also
better visualized by showing a vertical bar where to insert "in between", not by
holding one column above another. (I attach a screenshot, mouse cursor missing,
where one column C is moved between A and B).

If, for the sake of Excel-migrators, the Shift-key would become the default for
inserting, it would be great to get a configurable "Drag'nDrop: insert or
overwrite".

Hi,
yes, I agree to 8daysaweek: It would be fine to have an idea about the timetable.

8daysaweek, thanks for the hint with the Shift in Excel for inserting moved
columns/rows instead of overwriting the target.
As mentioned, in Lotus 1-2-3 inserting (instead of overwriting) is the default
when dropping, without pressing an extra key. 
To me, this is more intuitive than Excel, where I (at best) get a warning that
the target will be overwritten.  In the writer Lotus Word Pro, inserting is also
better visualized by showing a vertical bar where to insert "in between", not by
holding one column above another. (I attach a screenshot, mouse cursor missing,
where one column C is moved between A and B).

If, for the sake of Excel-migrators, the Shift-key would become the default for
inserting, it would be great to get a configurable "Drag'nDrop: insert or
overwrite".

Bye.

Created attachment 32878 [details]
Drag'Drop Lotus WordPro: See where moved column is inserted

Dragging and Dropping for rows would collide with selecting by holding the 
mouse-key and moving it over the row-numbers. 
 
Hence the behaviour would have to be changed to select only if the rwo was not 
selected before and drag, if it was selected when the user clicked on it. 
 
This issue causes a lot of clicks when re-arranging tables. 

No, I don't think so.  The behaviour requested is similar to that in Excel.  I
have re-read your message a number of times and cannot quite understand what you
mean?

The drag and drop would be the same as it is now, but holding down the shift key
would allow a row/column/cell(s) to be inserted between 2 existing rows/columns,
shifting their contents and not leaving a blank row behind.

No more clicks are required than now, as there is no suggestion of changing the
behaviour of selecting by clicking on row numbers, or for moving
rows/columns/cells in any way different to that already used.

> No, I don't think so.  The behaviour requested is similar to that  
> in Excel.  I have re-read your message a number of times and cannot  
> quite understand what you mean?  
  
Then try it out. Open Calc, click on a row-number, hold the button and  move  
the mouse. You will notice that calc selects the rows. Now click on one of the  
selected rows and hold the button, move it. You will notice that instead of  
dragging anything, calc just selects again, so if it would drag, the selecting  
as it works now would not work when clicking on a row that is already  
selected.  
  
> The drag and drop would be the same as it is now, but holding down  
> the shift key would allow a row/column/cell(s) to be inserted between  
> 2 existing rows/columns, shifting their contents and not leaving a  
> blank row behind.  
  
At the moment drag&drop does not work at all, if you try to click on the row 
numbers and move rows. The only thing that works is dragging cells, not 
columns, not rows. This is unintuitive, since when you d&d on the desktop, you 
always click on the item you selected, if you select by clicking on the 
row-numbers, you should be able to d&d by clicking on the row-numbers. 
  
> No more clicks are required than now, as there is no suggestion 
 
The current behaviour is what I meant, that is causing more mouse-clicks. 
 
> of changing the behaviour of selecting by clicking on row numbers, 
> or for moving rows/columns/cells in any way different to that 
> already used.  
 
IMO it makes sense to allow the user to move whole columns and rows without 
pressing some extra-key, i.e. by dragging a row and not cells, i.e. clicking 
on the row-number rather than on a cell. 

OK, I understand what you mean.  Yes that is the current behaviour, only cells
can be dragged, although I an entire row/column is selected then that entire row
/column can be moved by dragging the cells.

I am not sure that this in counter-intuitive, as the current behaviour means you
drag the cell(s) highlighted, rather than an indicative heading.  However, it
did take some getting used to for me, as I was accustomed to dragging
rows/columns in the way you describe.  So, I'm not certain which is best.
 
> IMO it makes sense to allow the user to move whole columns and rows without 
pressing some extra-key, i.e. by dragging a row and not cells, i.e. clicking 
on the row-number rather than on a cell.

I understand that completely, however *perhaps* those comments would be better
suited to another issue,(?) as this issue is not about the method of *grabbing*
and dragging the row/column, but rather about the ability to *insert* the
rows/cells/columns when dropping them, and so not leaving any blank rows or
columns behind.

Hello rabauke,

I agree to 8daysaweek that there's a little misunderstanding about the topic of
this issue, where you talked at cross-purposes. (Ein bisschen aneinander
vorbeigeredet, hm?)

OO Calc 2.0 *is* able to move selected rows and columns via drag 'n drop -- but
not by dragging the head of the row/column, where you have marked it. Instead,
you have to left-click on one of the highlighted cells (is black "highlighted?)
and drag it.
In Excel you also don't drag by the rows/columns head, but by clicking on outer
border line of the highlighted area, as to be seen by a changed mouse cursor
(arrow instead of cross).

Having cleared this, I hope, now to the intention of this issue: *How* the drag
'n drop is working today.
The row(s) where your drop the moving one(e), is/are simply overwritten, not
matters if they are empty. It is desirable to have the choice of *inserting* the
dragged rows/columns between others, so automatically moving the others ones
farther down/right. Excel does this, if you press Shift while dragging.

Was this understandable?
Dragging in a more intuitive way would be nice, too, e.g. with a changed
mouse-over cursor, as other do it: Excel (arrow instead of cross), Lotus 1-2-3
(browser-like hand).
But coming back to 8daysaweek: That would have to be another issue, in my opinion.

*** Issue 60624 has been marked as a duplicate of this issue. ***

I'd like to mention that those who need this feature can use the Calcmover macro
 ( http://sourceforge.net/project/showfiles.php?group_id=87718&package_id=146632
) from OOMacros.org ( http://www.ooomacros.org/user.php ). 
I've been using it, and it works fine.

Hello shreevatsa,

thank you for your hint about the Calcmover. I tried it, and -basically- it helps.

Though I don't want to be a perfectionist, I still miss the following:
a) Seemingly, Calcmover swaps two neighboring columns or rows. Can't you move
more than one row/column?
b) If I want to move column H to B, you have to click six times to get there, as
you move step by step instead of moving at once.
c) The test macro works quite slow, compared to the usual moving-function.

Have I misunderstood the handling of Calcmover? Then I'm sorry.
For me, this moving feature should become a basic feature as in Excel. The same
about the similar feature in Writer compared to Word (issue 13645).

Thank you.

Dirk

> Dragging in a more intuitive way would be nice, too, e.g.
> with a changed mouse-over cursor, as other do it: ...

Not to mention OOo Draw, where left-click initially selects (if not already
selected), then after a short delay changes to DnD, which is signaled by a
change in cursor shape.

DnD in Writer requires a selection first, then a separate drag.

IMO it is poor design for DnD to be destructive (i.e. replace data in the
destination), or certainly not as the default. DnD in Writer always inserts.

I'm not suggesting which is the best way, only pointing out that there are
several places where OOo already implements DnD, and somewhat inconsistently.
Adding further inconsistency at this point would detract from the added
functionality.

Dear developers,
any chance of implementing this feature in 2.3?

Changing the version to 2.0 since it still there, with the intention of being
easier to find it in the searches.

For the voters, please consider voting on issue #14007 since it blocks this issue.

Asrail, regarding your comment from January 12th:

> please consider voting on issue #14007 since it blocks this issue.
*This* is issue 14007. Do you mean voting additionally for issue 21280?

Sorry for the mistake, it's issue 21280.

Please see also issue #7180, which I'm currently working on.

Issue #7180 is fixed and will be integrated into OOo 2.4.
Due to technical reasons (I checked in the code with
the issue number #7180) I set this issue to duplicate
and not vice versa.

duplicate

*** This issue has been marked as a duplicate of 7180 ***

closed