Apache OpenOffice (AOO) Bugzilla – Issue 21036
Cut row and paste special crashes Calc
Last modified: 2013-08-07 15:13:02 UTC
1. Highlight an arbitrary row by clicking the row index on the left side. 2. Ctrl + X to cut the row. 3. Select a cell in the first column, and right-click & do Paste special. 4. Under Shift cells, the "Down" item is grayed out, so select "Right", and click OK. 5. A message pops up that reads "Filled cells cannot be shifted beyond the sheet". Click OK to close the message box. 6. Select an arbitrary cell, and type in something. 7. When you hit the enter, the mouse corsor chages to an hourglass, and after a bit of hard disk access sound, the error report dialog comes up, indicating that the application has just crashed. There are two things to note here. One is why is the Down item under the Shift cells group grayed when a row is cut into the clipboard? The other is of course the crash. When you copy a row instead of cutting it, however, you can successfully paste it with cells shifting down as expected. Kohei
Oops. typo.
Hi Niklas, one for you. Crash Report is send ID is rzpsj8. Frank
After cutting, "Shift cells" in Paste Special is disabled for the directions where the moved range and the cut source range intersect, because this would cause wrong updated references in formulas. The crash is fixed with CWS calc19 (viewfun3.cxx 1.22.266.1).
Niklas, Shift Down radio box is disabled even if the cut row and pasted row don't intersect. That's what's odd about this problem. For example, when I open a whole new document, highlight row 12 and cut it, select row 2, right-click and past special and the Shift Down box is still disabled. Obviously rows 2 and 12 don't intersect at all. On top of that, since this is a new document, there is no data in the sheet. Is this still not a bug? Kohei
I have reread my last posting, and the tone of my voice may have been a bit rude, for which I apologize. But I hope the remaining issue I have raised in my last posting (the issue of shift down box being disabled when cutting and pasting rows) will be treated as a bug, because I believe this behavior should be nearly identical between the action of *cutting* and pasting and the action of *copying* and pasting. Let me elaborate. When I copy and paste a row, I can select the "shift down" box in the paste special dialog box, and it does what it's expected to do (i.e. push the rows below the point of insertion). But when I cut and paste a row, the "shift down" box is disabled. If this is an expected behavior, it's a bit too confusing. I would personally call it a bug. Or should I closed this case and create a new issue with this particular problem? Thanks, Kohei
The difference between cut and copy here is that for cut&paste formula references are updated if they point to the cut cells. The inserting of cells (which is what "shift down" does) updates formula references, too. The update for the cut&paste won't find the original references if they were moved for inserting. The cells that are moved when shifting down are those below the destination cell range, which includes row 12 in the example. Rather than end up with wrong references, "shift down" is disabled in that case. If you think it's important to allow "shift down" in this case (taking proper care of references, so it's more than just enabling it in the dialog), feel free to open a new enhancement issue. It's generally preferable to have a separate issue for each problem. This issue's summary suggests it's about the crash. To get the fix for the crash through the usual process of QA verification and workspace integration, it has to stay that way and keep the "resolved/fixed" state.
Ahh, now I understand. Thanks Niklas for taking your time to explain the difference to me. And yes, I think it's important to add the shift down functionality when pasting cut cells with properly updated cell references, since the most popular spreadsheet program does just that. I will add enhancement request for this later. Kohei
Issue 21280 has been added for enhancement of the automatic "shift down" of cells when cutting and pasting. Kohei
Reassigning to QA for verification.
Back to fixed enabling the other changes to the state.
Found fixed on Cws Calc19 for Solaris, Linux and Windows
FST: As requested by TZ and AK back to you
It's already in a right childworkspace, so nothing to do for dev.
restoring fixed state
fixed I've said.
closing as I've found it fixed in internal build 645m21-3 on Linux, Solaris and Windows.
Found integrated on srx645m25s1-1 using Windows, Linux and Solaris Frank