Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||when cut/copy rows/columns & paste-special, shift down/right options are disabled incorrectly|
|Component:||editing||Assignee:||Shenfeng Liu <liushenf>|
|Status:||CLOSED FIXED||QA Contact:|
|Priority:||P3||CC:||amy2008, avagula, caiot1, christopheg, cmoulin, drichard, fanyuzhen, frank.loehmann, hans, hroush, internationils, issues, jsc, kozodaevroman, liushenf, mail.info, mfedyk, mr_smyle, openoffice, openoffice, pagalmes.lists, peschtra, pobox, samphan, steve.yin.aoo, stp, tantai, tatat, thomas.lendo|
|Version:||OOo 3.2.1||Keywords:||oooqa, rfe_eval_ok, usability|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
Description kyoshida 2003-10-15 20:19:45 UTC
This issue has spun off from Issue 21036. When you cut a row by selecting its row index and ctrl+X, and paste it into an empty row through paste special, the automatic "shift down" of cells below the point of insertion is disabled in the current version of OO.o (1.1). I request for enabling this feature with proper updates of cell references if formulae are found in the affected cells. This feature will be equivalent of "Insert cut cells" in MS Excel. I believe inclusion of this feature will save us a few keystrokes as well as some aggravation for those former Excel users who are used to this feature. Thanks, Kohei
Comment 1 niklas.nebel 2003-10-17 19:23:25 UTC
Bettina handles enhancement issues.
Comment 2 everard 2004-03-11 05:04:48 UTC
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.
Comment 3 frank 2004-04-07 09:35:16 UTC
*** Issue 27520 has been marked as a duplicate of this issue. ***
Comment 4 kevinnehls 2004-09-17 05:30:34 UTC
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
Comment 5 frank 2004-10-15 11:52:31 UTC
*** Issue 35298 has been marked as a duplicate of this issue. ***
Comment 6 lohmaier 2004-10-23 21:59:22 UTC
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.
Comment 7 sparcmoz 2004-10-23 23:54:46 UTC
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.
Comment 8 everard 2004-10-24 23:56:28 UTC
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).
Comment 9 alura 2004-12-09 16:29:19 UTC
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
Comment 10 peschtra 2004-12-18 15:56:10 UTC
*** Issue 27630 has been marked as a duplicate of this issue. ***
Comment 11 peschtra 2004-12-18 16:01:27 UTC
Changing the summary to be more inclusive more easily searchable. Included columns and insert in the summary.
Comment 12 peschtra 2004-12-18 16:05:19 UTC
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.
Comment 13 skwashd 2005-01-08 10:26:18 UTC
Bug Spam - me too :) At least make this a user pref. TIA
Comment 14 christopheg 2005-01-19 08:35:16 UTC
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.
Comment 15 lohmaier 2005-01-19 17:44:10 UTC
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.
Comment 16 christopheg 2005-01-20 04:26:28 UTC
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).
Comment 17 ma2412ma 2005-05-04 12:31:06 UTC
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.
Comment 18 iavor 2005-05-22 17:18:36 UTC
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?
Comment 19 iavor 2005-05-22 17:24:35 UTC
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.
Comment 20 kevinnehls 2005-05-22 20:16:31 UTC
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.
Comment 21 iavor 2005-05-23 12:55:06 UTC
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.
Comment 22 frank 2005-05-24 10:43:10 UTC
*** Issue 48951 has been marked as a duplicate of this issue. ***
Comment 23 iavor 2005-05-24 11:48:19 UTC
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.
Comment 24 frank 2005-06-29 11:28:19 UTC
*** Issue 50753 has been marked as a duplicate of this issue. ***
Comment 25 frank 2005-06-29 11:29:52 UTC
*** Issue 51168 has been marked as a duplicate of this issue. ***
Comment 26 frank 2006-03-10 14:13:46 UTC
*** Issue 55995 has been marked as a duplicate of this issue. ***
Comment 27 frank 2006-07-07 13:08:44 UTC
*** Issue 65561 has been marked as a duplicate of this issue. ***
Comment 28 shreevatsa 2006-07-07 17:29:00 UTC
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>.
Comment 29 gtimur 2006-12-25 14:33:18 UTC
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"
Comment 30 caiot1 2007-01-13 00:47:27 UTC
Changing the version to 2.0 since it still there, with the intention of being easier to find it in the searches.
Comment 31 surbun 2007-05-04 09:13:43 UTC
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)
Comment 33 pagalmes.lists 2007-07-26 12:17:55 UTC
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
Comment 34 ds13 2007-07-26 21:42:23 UTC
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!!
Comment 35 pagalmes.lists 2007-07-27 08:22:39 UTC
ds13 -> you just have to press ATL to activate it, as explained in the spec. For more info, please read the spec.
Comment 36 frank 2007-08-01 13:35:34 UTC
*** Issue 76895 has been marked as a duplicate of this issue. ***
Comment 37 frank 2007-08-27 11:15:14 UTC
*** Issue 81041 has been marked as a duplicate of this issue. ***
Comment 38 frank 2007-10-29 11:35:52 UTC
*** Issue 46738 has been marked as a duplicate of this issue. ***
Comment 39 frank 2007-10-29 11:45:15 UTC
*** Issue 83046 has been marked as a duplicate of this issue. ***
Comment 40 lohner 2007-12-13 12:26:02 UTC
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!
Comment 41 lohner 2007-12-13 12:26:42 UTC
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...
Comment 42 lohner 2007-12-13 12:45:56 UTC
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 )
Comment 43 gtimur 2008-03-28 15:26:43 UTC
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.
Comment 44 frank.loehmann 2008-05-22 09:32:17 UTC
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.
Comment 45 brianpeyser 2008-06-08 18:45:21 UTC
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.
Comment 46 cjw296 2008-08-12 14:35:06 UTC
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.
Comment 47 warrior161 2008-08-12 16:34:02 UTC
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.
Comment 48 jgfuller 2008-08-12 19:15:12 UTC
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
Comment 49 cjw296 2008-08-12 19:21:24 UTC
@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 ;-)
Comment 50 ds13 2008-08-12 21:41:39 UTC
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.
Comment 51 cjw296 2008-08-13 09:39:45 UTC
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?
Comment 52 amy2008 2008-09-19 04:33:24 UTC
*** Issue 85187 has been marked as a duplicate of this issue. ***
Comment 53 amy2008 2008-09-19 04:35:47 UTC
CC to Li Meiying
Comment 54 corigo 2008-10-06 10:27:00 UTC
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!
Comment 55 villeroy 2008-11-03 20:16:06 UTC
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
Comment 56 jgfuller 2008-11-03 21:14:58 UTC
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?
Comment 57 vince 2009-06-16 23:04:49 UTC
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.
Comment 58 Regina Henschel 2009-08-02 02:11:09 UTC
*** Issue 103094 has been marked as a duplicate of this issue. ***
Comment 59 j27 2009-12-08 02:51:31 UTC
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!
Comment 60 exexcel 2009-12-08 15:08:44 UTC
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!
Comment 61 samphan 2010-07-14 12:05:10 UTC
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.
Comment 62 jgfuller 2010-07-17 17:00:14 UTC
This might be a "logical issue", but its absence is a powerful incentive to keep using MS Office.
Comment 63 Shenfeng Liu 2014-01-14 08:44:44 UTC
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.
Comment 64 jsc 2014-01-14 09:56:03 UTC
next time please provide patches with full path, at least beginning from main and no CRs.
Comment 65 Shenfeng Liu 2014-01-14 11:10:50 UTC
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...
Comment 66 Shenfeng Liu 2014-01-14 13:52:42 UTC
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...
Comment 67 Shenfeng Liu 2014-01-15 14:06:48 UTC
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!
Comment 68 jsc 2014-01-15 15:28:26 UTC
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
Comment 69 Shenfeng Liu 2014-01-16 01:29:40 UTC
(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.
Comment 70 jsc 2014-01-16 11:05:02 UTC
ok, reviewed and applied
Comment 71 SVN Robot 2014-01-16 11:05:58 UTC
"jsc" committed SVN revision 1558753 into trunk: #21280# apply patch to enable/disable shift cell options depending on the cop...
Comment 72 Shenfeng Liu 2014-01-17 08:33:25 UTC
(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.
Comment 73 fanyuzhen 2014-02-26 09:42:13 UTC
Verified by Edwin Sharp on Jan 28: Bug is fixed - shift cells down is enabled
Comment 74 Steve Yin 2014-04-03 06:59:50 UTC
Verified on branch AOO410. Rev. 1583666