Issue 21280

Bettina handles enhancement issues.

This should also apply to columns that are cut and pasted.  Right click could
give insert column/row or paste column/row and column/row could then be inserted
(shifting next column/row) or pasted over the selected column/row.  I think
inster should be the default behavoir as it is safer.

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

I would love to see this feature added.  I wish for it every time I copy a row
and right-click on another row to insert that copied row.

Instead I have to insert a new row then paste.  When you do this a lot, it can
be very aggravating.

But I'd like to see it for more than just cutting a row, cell or column.

Here's what I'd like to see:

1) Copy a cell, row or column

2) Right-click on a cell, row or column (respectively)

3) Context menu now pops up with an "Insert Copied Cells..." option where the
"Insert" option normally is.

Now to one up Microsoft.  Instead of just letting this happen once.  Leave that
option there until the user performs a different action, like typing in another
cell, clicking in the input bar, clicking on a button or selecting another
command from a pull-down menu.

This functionality should also work across the different sheets (tabs) in a
spreadsheet and even between different workbooks.

Kevin

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

setting keywords, reassigning according to new RFE-process.

Sum-up: 
When copying a row the option to move rows down is selectable.
When cutting a row the option cannot be chosen, it is disabled.

The same is true for columns (with "move right" instead of "move down" of course)

The option should be available, no matter whether the user uses cut or copy.

This would be a very useful feature for users, in my experience it is most usual
that a cut row needs to be inserted somewhere else.

  The number of duplicates of this issue shows how much it is needed in OOo.  I
don't know how many votes are needed to push an issue forward but is there any
other way of improving the status of this request - a poll somehwere or something?
  A similar issue is one I started  (26329)  regarding non-contiguous cut and
paste, ie holding down the ctrl key to select parts of a row(s) or column(s)
then copy and pasting.  Cells can currently be selected in this way but not
copied or pasted.
  Pehaps we could push for these issues to be implemented together.  As they are
both available in Excel and a lot of people use them (at least in my field -
science).

This behavior change from release 1.1.2 to 1.1.3 had broken paste function when
you have merged cells of different sizes toward the insertion point.  "Shift to
xx" when pasting after cut or copy should be configurable.  Other possible
solution might be to have different behaviors for cutted cells than for copied ones.

For this problem to occur you might try:
1) create a merged cell of say 3 columns wide.
2) Create another merged cell of say 4 columns wide below the first one.
3) Try pasting a 3 colums wide range above the first merged cell.
===> "Inserting into merged ranges not possible" error message.
(this should work for "shift down" paste)

Please advice if I should open this issue in a different thread.
Thanks in advance,
     Mauricio

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

Changing the summary to be more inclusive more easily searchable. Included
columns and insert in the summary.

This would be a very nice feature.

If this can't be done, it would also be nice if the paste special options could
be changed instead. Right now if I select a column and cut it, then choose paste
special in a new column shift option is greyed out. However, if copy the coklumn
and past special, the shift right option is availbe, but then I have to go back
and delete the original column.

It would be nice to use paste special as a workaround.

Bug Spam - me too :)

At least make this a user pref.

TIA

There is a major problem with this issue as described in the summary.
The proposed behavior is handy and save keystokes when applied to rows of
columns but definitly not when applied to individual cells inside the sheet.

The problem is that you shift part of a row and you desynchronize data, say if
you have a grid item / price, you use paste to insert a new item... it's
inserted... and you get your price list all wrong.

OOO 1.3 Debian version is behaving this way and it's a major problem (see closed
issue 40204, closed because it's debian specific).

Is this issue is for moving full rows or columns it's ok. If it's for cells
too... I whish I could vote *against* it.

initial comment:
> I request for enabling this feature with proper updates of cell references
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Since OOo currently is not able to do this the option to move rows is disabled
(hence this RFE).
Debian enabled the option without taking care of the references.

initial comment:
> I request for enabling this feature with proper updates of cell references
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Even with proper update of reference it still would be good *only* for full rows
or full columns. *not* for individual cells. Without any reference it still can
easily break line semantics (it is not a better idea as would be randomly
changing data between records in a database).

Since a lot of people (including me) really need this feature, I wanted to ask
about the current state of this bug. For me, it would be sensible to enable this
"Shift Down" when cutting and pasting special, just like Debian did - if the
equations get messed up, so what? That can/will be (hopefully) fixed in a future
version of OOo, but in the meantime those people requesting this feature could
be satisfied. Especially because IMHO the majority of those people are using OOo
just for editing imported data files and want to cut and past, i.e. sort the
rows, so there are no equations at all.

I can not imagine that there are people who can live without this feature? I
just decided finally to completely move from Microsoft Office to OpenOffice, as
I consider OpenOffice (1.9+) now stable and feature rich enough for my needs,
and if there is one single feature that kills me it is this one. How can we push
it further?

I would also add that the cut rows/columns must be really cut. Now (1.9.100) the
data and formatting are cut, but the rows/columns remain. So after the paste one
should come  back and delete these rows/columns. Perhaps this is filed in
another bug? Issue 39405 sounds a bit llike this, but not entirely.

um, guys, you can use ctrl+shift+v to get the Paste Special dialog box.  So you
can get off the "can't use OOo without this feature" soap box.

While I agree that OOo should have this extra functionality it is far far far
from being a show stopper.

This feature should not be an automatic insert either.  There should be an
insert cut or copied cells on the right-click menu, but it should not be
automatic when pasting.

Additionally, cut, should not cut the row or column, it should only cut the
contents.  That is what delete column /  row is for.  If you want a cut row or
column feature request it as a separate feature, but do not modify the existing
cut functionality.

I do not want to start a usability discussion and I do not know if here is the
right place to discuss this.

For me the need for 'cut' to cut also the rows is so obvious that I can't
imagine why somebody would need the rows to stay? I mean, I have used Excel 8
hours a day for 10 years and I do not remember to have needed it that way.

About 'insert cut cells' - how do you ever sort a spreadsheet without this?
People who spend their days doing 'cut->insert cut cells' will tell you that
this is a big stopper for them. Otherwise the scenario is - cut, scroll N pages,
inser cut cells (when exists), scrol N pages back, delete the empty rows. Do you
think this is very practical if you have to do it 15-25 times?

I agree that 'paste' should not do 'insert', but at least there should be
'insert cut cells' in the right mouse button context menu.

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

Actually I have to say that I noticed something nice. In OO after CUT ROWS it is
possible to do INSERT ROWS without OO forgetting the CUT and then PASTE. The
reason I did not do it is that Excel tends to 'forget' selections if another
operation is done before the PASTE or INSERT. So it is a habit/usability problem
rather than anything else and the situation is not as bad as I thought.

Perhaps a lot can be improved if the nice advisor is linked to the CUT event
with explanation for deformed Excel users like me how they can do PASTE INSERT
by doing first insert rows and then paste.

INSERT CUT ROWS would be of course better, especially for large blocks, as now
with insert -> paste one should count a lot, but the situation is not that acute
as I originally thought, at least not when one to few lines are moved around.

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

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

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

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

I'd like to mention that those who need this feature can use the <a
href="http://sourceforge.net/project/showfiles.php?group_id=87718&package_id=146632">Calcmover
macro</a>  from <a href="http://www.ooomacros.org/user.php">OOMacros.org</a>.

I don't understand why it takes 3 years to implement this. This is very
important in Calc and using "Paste Special-Shift Cells Down" and deleting empty
row after that all the time is annoying. 
What i would like to see is just another command on right-click menu "Insert
Copied Cells" or "Insert Cut Cells"

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

Working with the 2.2.0 version. Bug (meaning impossibility to add or delete row
or colomn when cells are merged)still there even in newer version 2.3.0 (still
on test)

Isn't issue 46738 related to this also?

Here is an interresting new feature that may solve partly this issue:


*Description*
-------------
When moving or copying a marked cell range via drag & drop to
a new row or column, by default the target cells are overwritten.
An insert drag & drop mode can be activated by pressing the ALT key
in addition to the SHIFT and CTRL keys before dropping.
In this case the source data are inserted at the new position,
that means the target cells are shifted to the right or down.
In the insert drag & drop mode also a new preview cursor is shown.


*Specification URL*
-------------------
http://specs.openoffice.org/calc/ease-of-use/Insertion_of_Cells.odt

Hello pagalmes,

please clarify to avoid misunderstanding: Do you really have to press CTRL plus
SHIFT plus ALT to activate insertion?

I have understood the specification document that way, that you only have to
press ALT for "move insert" (like SHIFT in Excel), at least with drag and drop
via mouse.
http://specs.openoffice.org/calc/ease-of-use/Insertion_of_Cells.odt

The original request here in #21280 was about keyboard handling, I think - but
nevertheless great, that this feature will become available!!

ds13 -> you just have to press ATL to activate it, as explained in the spec. For
more info, please read the spec.

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

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

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

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

Would be interesting to see what rank this bug is up to in voting, but
http://qa.openoffice.org/iz_votes.html is outdated (see bugs 79840 and 84530)

I'd love to see this get resolved; how can we get this issue pushed?  Its a big
productivity blocker and generates errors in larger cut/paste insertions if you
accidentally overwrite lines!

Would be interesting to see what rank this bug is up to in voting, but
http://qa.openoffice.org/iz_votes.html is outdated (see bugs 79840 and 84530)

I'd love to see this get resolved; how can we get this issue pushed?  Its a big
productivity blocker and generates errors in larger cut/paste insertions if you
accidentally overwrite lines!

Plus, this bug is now open for 4 years and 2 months... 

Issue 7180 looks like a sibling of this and is fixed/closed in 2.4, so there may
be hope yet!  Timetable: Release in March 2008 (see
http://wiki.services.openoffice.org/wiki/OOoRelease24 )

Now, if you try to paste cut cells to some cells containing data, you have a
warning "Do you want to overwrite...?" "Yes" is logical, but "No" is not. You
don't paste your data and you lose your source cells, because they are cut,
unless you remember to paste it again.
Instead of Yes-No, there should be Overwrite-Insert-Cancel choice, not an
automatic insert. 
As noted before, there should be also "Insert Copied Cells" or "Insert Cut
Cells" on right-click menu.

This issue is important and listed on the quarterly review for Calc:
http://wiki.services.openoffice.org/wiki/2008_Q2_Review_of_Spreadsheet_Project
Therefore adjusting target to 3.x.

I used this feature of Excel (before I moved to OOo Calc completely) for
re-ordering columns. I really want to see this as a context menu (right-click)
option. The drag & drop functionality mentioned by pagalmes, referenced in:
http://specs.openoffice.org/calc/ease-of-use/Insertion_of_Cells.odt
does the job well. 

Summary: first just select the row/column or other cell range, then click WITHIN
(not on a column header, for example) and drag the selection to where you want
it. Press ALT to insert rather than overwrite. When ALT is used for insertion,
the source cells are removed (YAY!). When ALT isn't used the source cells
remain, and just the contents are moved (acts just like cut/paste). This works
great for re-ordering columns or rows. You just select the entire row/column
then drag-and-drop to where it should go using ALT. You can also combine this
with CTRL to make a copy (if CTRL+ALT is used the source cells remain, of course).

However, the exact same functionality would be nice to have as a context menu
(right-click) option as requested. I didn't even know about the drag-and-drop
until I saw it here. So big thanks to pagalmes for educating me!

-Brian D. Peyser, Ph.D.

Just to try and sum up what I can make of what this issue is about, people are
after:

1. having "insert [copied|cut] [rows|columns|cells" as a right click menu option

2. copied rows/columns/cells to be inserted by default rather than overwriting
existing content. The "warning, you're about to overwrite data" in OOo 3 is just
annoying :-( This warning should be an "insert/overwrite/cancel" option as 
gtimur suggests *and* a checkbox there that says something along the lines of
"do this from now on rather than popping up this annoying dialog box" ;-)

3. when cutting whole rows or columns using the keyboard or right-click-cut,
have the original rows removed rather than blanked.

Should we split these out into three seperate issues or keep them all here as one?

@brianpeyser: that is a different piece of functionality. It achieves the same
ends but doesn't cater for the cultural constraints Excel has imposed to be
useful for the majority of users. It's also not hinted at, but I'm going to
raise a separate issue about that.

Excel handles this issue perfectly, and that is the functionality required.

This is a showstopper for me as I find OO so tiresome as to be unuseable 
without it, and I continue to use Office 2000.

Sadly the Beta 3 version of OO doesn't include it.

In the comment of cjw296, it is item 1 that is the current functionality in
Excel and is displayed in a right-click menu.

1. having "insert [copied|cut] [rows|columns|cells" as a right click menu option

@warrior161: the bellyaching is unnecessary.
See http://specs.openoffice.org/calc/ease-of-use/Insertion_of_Cells.odt for a
way to do what you want to. Once you use it, it's easier than you were used to
with Excel. I do agree with you that it would be great if OOo mirrored Excel in
this but if it's really that big a deal for you then nothing's stopping you
diving into the code and implementing it yourself ;-)

Hello,

I just looked into Excel 2000:
- Drag without key = move and overwrite (after OK)
- Drag with Shift  = move and insert
- Drag with Ctrl   = copy and overwrite (without question)
- Drag with Ctrl+Shift = copy and insert
- Drag with Alt    = same as without key

Surely, it would be nice to be "compatible" (meaning: recognizable) for Excel
users, but at least you can configure keyboard settings for yourself.
They main point is to have the functionality (move+insert) available at all.

cjw296, in your posting from 13:15 today you gave a pretty nice summary of the
single topics. In my opinion, they should be independent issues, because they
aren't the core requirement of this issue's basic requirement anymore, but just
following wishes.

However you decide, the default behaviour of both Cut and Copy should be the
same concerning insertion<-->overwrite.
When cutting a complete row/column, Excel's context menu offers both "Insert"
(leaving the old row/column empty and overwriting) and "Insert cut cells"
(moving and inserting).

Bye.

How do we go about splitting this issue?
Does this tracker support proper issue splitting or do we just open the three
issues manually and close this one?

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

CC to Li Meiying

I agree that the specification was helpful, though canceling a drag and drop 
between sheets left me looking at the target sheet and a bit lost. Still as any 
drag and dropper knows, dragging and dropping in a long spreadsheet is 
extremely difficult! Scrolling speeds vary tremendously by processor and memory 
available in any specific PC. Anybody who offers me a drag and drop solution 
will only receive my scorn. This is what drove me away from Apple and now 
Ubuntu. Please activate the same functionality from a right click paste so that 
I can easily and assuredly put in the correct place without the mad up/down 
left/right scrolling assured in D&D!

Just look at that vote count!

Seemingly the issue has been resolved in v3.0 but not in v2.4.2, whereas there
is at least one issue that has been resolved in 2.4.2 but not in 3.0:
http://qa.openoffice.org/issues/show_bug.cgi?id=59745

In 3.0 there is still not a right-click "Insert cut [or copied] cells" choice. 
How is it that this issue is now resolved in 3.0?

There is no keyboard equivalent to this functionality, which is heavily missing.

In Microsoft Excel I can cut a whole row or column with Ctrl+X and just press Ctrl
+<plus> in order to move it from one place to another.

While all those right-left-drag-click thingies are very nice for the beginner, they 
are almost superfluous for every power user.

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

On a sheet where there are formulae, eg column A contains values and column B
contains cumulative totals (ie B2=B1+A2, etc), moving a row further down the
sheet is not simple.  It is possible (in OpenOffice 3.1.1) to move a row by
selecting it, dragging a selected cell down, and pressing ALT before releasing
the mouse (which isn't intuitively obvious, but is very useful).  However, the
formulae are badly messed up as a result.  Moving the current row 3 down one row
(ie swapping rows 3 and 4) results in B2=B1+A2 (good), B3=B4+A3 (bad), B4=B2+A4
(bad), B5=B3+A5 (bad), B6=B5+A6 (good).  So three formulae are wrong in this
case.  The user then has to fix the spreadsheet manually, although it is not
likely to be obvious that the formulae are now out of step.

For users who haven't discovered the little-known ALT key functionality they
would have to use the following method.  First the new row location must be
created as a blank row, but the cumulative formula for the line below is
distorted, eg if B5 contained =B4+A5 the cell that it moves to (B6) becomes
=B4+A6 (wrong).  Next, the row to be moved is copied and pasted over the newly
inserted blank row (noticing that the total at the bottom doesn't change, which
is sad).  Finally the original row is deleted and the formulae below it all show
"#REF!".

The user is then left to repair the damage.

The Excel feature "insert cut cells" is very useful and some equivalent in
OpenOffice would make such work much more pleasant and less prone to error.

Perhaps the version should be advanced to 3.1 since the problem still exists?

Thanks for your great product!

yeah, user j27 is sooooo right. we also miss this feature. my girl friend
switched from excel 97 (yes, that's from 12 years ago!) to open office and is
missing it regularly!

This is a very complex bug report so I want to summarize things up here.

There are 4 cases:-
A: user want to copy a row
B: user want to move a row
C: user want to copy a column
D: User want to move a column

A: user want to copy a row
1. select a row then Ctrl+C
2. right-click on the head of another row
3. select paste-special
Current behavior: "shift cell down" and "shift cell right" is enabled
Expected behavior: only "shift cell down" should be enabled

B: user want to move a row
1. select a row then Ctrl+X
2. right-click on the head of another row
3. select paste-special
Current behavior: "shift cell right" is enabled
Expected behavior: "shift cell down" should be enabled instead

C: user want to copy a column
1. select a column then Ctrl+C
2. right-click on the head of another column
3. select paste-special
Current behavior: "shift cell down" and "shift cell right" is enabled
Expected behavior: only "shift cell right" should be enabled

D: User want to move a column
1. select a column then Ctrl+X
2. right-click on the head of another column
3. select paste-special
Current behavior: "shift cell down" is enabled
Expected behavior: "shift cell right" should be enabled instead

Considering the way OOo illogically enable/disable the "shift cell down/right"
options, I think this is not a missing feature but a bug in the logic to
enable/disable the options. I also take this chance to change the summary and
issue type. This is a well-known bug that a lot of users reported to us for
several years.

This might be a "logical issue", but its absence is a powerful incentive to keep
using MS Office.

Created attachment 82276 [details]
fix patch

A patch that corrected the logical to enable shift down and shift right radio buttons when cut whole row or whole column.

next time please provide patches with full path, at least beginning from main and no CRs.

Juergen, sorry that I just realized that this patch still has problem. I will think more about it and re-fix it later.
Not sure how to withdraw this patch...

1. I looked through the original code in cellsh1.cxx that lead to the disable of shift down/shift right, whose purpose seems to be preventing the overlapping of the cut area with paste area. But the result is that many reasonable user scenarios were also disabled, even no overlapping.
So firstly I just tried to remove this part of code and let shift down/shift right allowed for every cut scenarios, including the overlapping with paste areas. And it looks working without problem.

2. The next question is, how to disable shift right when copy/cut full row, or shift down when copy/cut full column. I think we should judge it by if the pasted contents will be beyond the sheet. I'm still figuring how to do it...

Created attachment 82294 [details]
fix patch V2

Updated a new fix patch.

In the patch, the old rule of disabling shift down / shift right during cut (whose intention was to avoid cut area and paste area overlapping) was removed.

The new rule is: if the paste area will be beyond sheet range of max row or max column, the corresponding shift down / shift right will be disabled. And this rule apply to both copy and cut.

Please help to review. Thanks!

I have to confess that I am not 100% sure if it is now the wanted behaviour.

AOO 4.0.1
1. select row and copy ctrl-c
1.1 paste row via paste special -> shift cells, all 3 options are enabled
2. select row and cut ctrl-x
2.1 paste row via paste special -> shift cells, "down" is disabled

3. select column and copy ctrl-c
3.1 paste column via paste special -> shift cells, all 3 options are enabled
4. select column and cut ctrl-x
4.1 paste column via paste special -> shift cells, "right" is disabled


AOO4.1.0 dev
1. select row and copy ctrl-c
1.1 paste row via paste special -> shift cells, "right" is disabled
2. select row and cut ctrl-x
2.1 paste row via paste special -> shift cells, "right" is disabled

3. select column and copy ctrl-c
3.1 paste column via paste special -> shift cells, "down" is disabled
4. select column and cut ctrl-x
4.1 paste column via paste special -> shift cells, "down" is disabled

Any comments

(In reply to jsc from comment #68)
> I have to confess that I am not 100% sure if it is now the wanted behaviour.
> 
> AOO 4.0.1
> 1. select row and copy ctrl-c
> 1.1 paste row via paste special -> shift cells, all 3 options are enabled
> 2. select row and cut ctrl-x
> 2.1 paste row via paste special -> shift cells, "down" is disabled
> 
> 3. select column and copy ctrl-c
> 3.1 paste column via paste special -> shift cells, all 3 options are enabled
> 4. select column and cut ctrl-x
> 4.1 paste column via paste special -> shift cells, "right" is disabled
> 
> 
> AOO4.1.0 dev
> 1. select row and copy ctrl-c
> 1.1 paste row via paste special -> shift cells, "right" is disabled
> 2. select row and cut ctrl-x
> 2.1 paste row via paste special -> shift cells, "right" is disabled
> 
> 3. select column and copy ctrl-c
> 3.1 paste column via paste special -> shift cells, "down" is disabled
> 4. select column and cut ctrl-x
> 4.1 paste column via paste special -> shift cells, "down" is disabled
> 
> Any comments

Juergen: Your description above is correct for what I desired for the AOO 4.1.0 behavior in my patch.

ok, reviewed and applied

"jsc" committed SVN revision 1558753 into trunk:
#21280# apply patch to enable/disable shift cell options depending on the cop...

(In reply to jsc from comment #70)
> ok, reviewed and applied

Thanks, Juergen. I can see the code checked in now. And will test it when the build is available.

Verified by Edwin Sharp on Jan 28:
Bug is fixed - shift cells down is enabled

Verified on branch AOO410. Rev. 1583666