Created attachment 55043 [details] document to illustrate the described problem This bug is a bit difficult to show because of bug 42265, but can be reproduced by using a macro that bypasses the problem of bug 42265. -use the simple document that I have attached; -select columns D,E,F; -cut; -select cell A1; -use paste special with 'move cells to right' or use following basic macro with the following code to bypass the disabled option problem: sub insCol dim document as object dim dispatcher as object document = ThisComponent.CurrentController.Frame dispatcher = createUnoService("com.sun.star.frame.DispatchHelper") dim args2(5) as new com.sun.star.beans.PropertyValue args2(0).Name = "Flags" args2(0).Value = "A" args2(1).Name = "FormulaCommand" args2(1).Value = 0 args2(2).Name = "SkipEmptyCells" args2(2).Value = false args2(3).Name = "Transpose" args2(3).Value = false args2(4).Name = "AsLink" args2(4).Value = false args2(5).Name = "MoveMode" args2(5).Value = 1 dispatcher.executeDispatch(document, ".uno:InsertContents", "", 0, args2()) end sub 'insCol -note that the formulas that were in C1 and C2 and are now in F1 and F2 no longer produce the sum of the two cells to their left. Bug is also present in master, and occurs with Windows and with Linux. I suspect a connection with bugs 42261 and 27987 as these also report problems after inserting/delting/moving columns/rows.
Reproductible using your macro with both LibO 3.4.4 and 3.5.0 beta2 running on windows vista. But not reproduce using shorcuts : 1. Select column D E & F 2. Cursor in one cell of those columns 3. Drag in the first column with mouse 4. Press Alt key before drop. This way, I have expected result with both versions.
(In reply to comment #1) > Reproductible using your macro with both LibO 3.4.4 and 3.5.0 beta2 running on > windows vista. > > But not reproduce using shorcuts : > 1. Select column D E & F > 2. Cursor in one cell of those columns > 3. Drag in the first column with mouse > 4. Press Alt key before drop. > > This way, I have expected result with both versions. I didn't know this shortcut, it provides an alternative solution as long as the bug itself isn't solved. Unfortunately, bugs 42261 and 27987 still occur with this shortcut.
I made a typing error: for bugs 42261 and 27987 read bug 42261 and bug 37987 I'm sorry...
Created attachment 55074 [details] document to illustrate the described problem When using shortcut Alt, another, related, problem shows. Use tabsheet 2 -select row E; -drag the row to cell C1 with the mouse, keep mouse button pressed down; -press _right_ Alt-key (or Ctrl-key) and release mouse button; -column is copied, formula in pasted column reports error. When doing this with the _left_ Alt-key the column is moved and no error occurs in the formula. version 3.4.4, Windows XP. on master (code updated yesterday) and openSUSE 12.1 the behaviour with Ctrl-key is the same. With right Alt-key the behaviour is identical with left Alt-key (i.e. move).
Well, there's a reason that "shift cells right" is disabled on source rows once you have cut the range, it messes around with positions that aren't part of the document anymore but in the clipboard instead. Tricking that into bypassing the disabled option is just not nice ;-) So we'll need to respect the proper state when evaluating the API call and make it fail.
(In reply to comment #5) Given that there is a reason, the use of dragging in combination with right Alt-key should be disabled too. Also, why is the macro (uno:InsertContents) allowed then? But it may be that there is a misunderstanding: IMHO when moving columns, shift cells right should be enabled and shift cells down disabled and when moving rows vice versa.
(In reply to comment #4) > Created attachment 55074 [details] > document to illustrate the described problem > > When using shortcut Alt, another, related, problem shows. > Use tabsheet 2 > -select row E; > -drag the row to cell C1 with the mouse, keep mouse button pressed down; > -press _right_ Alt-key (or Ctrl-key) and release mouse button; > -column is copied, formula in pasted column reports error. > > When doing this with the _left_ Alt-key the column is moved and no error > occurs in the formula. > > version 3.4.4, Windows XP. > > on master (code updated yesterday) and openSUSE 12.1 the behaviour with > Ctrl-key is the same. With right Alt-key the behaviour is identical with > left Alt-key (i.e. move). Alt-problem still reproducible with version 3.6.4.3, Windows XP (left Alt is OK, right Alt is not), but not with version 3.5, openSUSE12.2. Ctrl-problem stiil reproducible on both Windows XP and openSUSE 12.2.
(In reply to comment #5) > Well, there's a reason that "shift cells right" is disabled on source rows > once you have cut the range, it messes around with positions that aren't > part of the document anymore but in the clipboard instead. Tricking that > into bypassing the disabled option is just not nice ;-) > > So we'll need to respect the proper state when evaluating the API call and > make it fail. Now that the shift options in the paste special dialog are disabled/enabled as meant to (i.e. disable when source and destination area intersect), I did some additional tests with the sample document. I used copy this time to avoid messing around with positions that aren't part of the document anymore (but only in the clipboard). Sheet1: 1. select D1:F4 2. (Ctrl+C) copy 3. select A1 4. Ctrl+Shift+V, paste special dialog opens 5. select shift right and paste 6. cells in row 1 have expected values, but I expected cells C2 and I2 to have the same value (6), which they have not. The references are absolute, yet cell I2 has its references shifted and cell C2 has not. Test done with version 4.1alpha+ on openSUSE12.2
Created attachment 81443 [details] sample document 2 Attached document can be used to demonstrate the problem. 1. open document 2. select range A1:A2 2. copy (Ctrl+C) 3. select cell C1 4. open paste special dialog (Shift+Ctrl+V) 5. select shift right 6. paste 7. expected behaviour: at least one of the pasted cells (C1:C2) should still have the same result as in the cells (A3:A4) which contain sthe same formulas as in (A1:A2). actual behaviour: both pasted cells have now changed results. This means that there is currently no way to copy & shift+paste without breaking formulas containing references to shifted cells. Probably the copied (but not yet pasted) cell's contents are not updated when the shift takes place so that the pasted cells have incorrect references in the formulas.
> 7. expected behaviour: at least one of the pasted cells (C1:C2) should still > have the same result as in the cells (A3:A4) which contain sthe same > formulas as in (A1:A2). No. When copy&pasting formulas references are never adapted and relative references always point to the same relative offset as the original, which here for A1 (=D1) is 3 columns to the right, maintained after pasting into C1 (=F1), and absolute references don't change at all (A2:=$D2 stays C2:=$D2). This is the same for normal copy&paste without shifting cells. What happens internally is that the cells are shifted before the content is pasted (which is logical because otherwise to be pasted content could overwrite to be shifted content before that is shifted). It seems regarding reference handling you expect: a) when shifting cells the references are updated in the clipboard as if they were already inserted in the sheet, with all so far usual reference updating, which means after paste the result will be C1:=G1 and C2:=$E2 Another but illogical handling would be b) references are treated as if the content was pasted before the cells are shifted, but if that was done then the shift would include the already pasted cells and they would end up in column D instead of column C; I don't think this was meant. For a) we'd need a different implementation of clipboard and reference update handling for the copy&paste+shift case.
(In reply to comment #10) > a) when shifting cells the references are updated in the clipboard as if > they were already inserted in the sheet, with all so far usual > reference updating, which means after paste the result will be C1:=G1 > and C2:=$E2 I will dig a bit into the code and see if I can determine what needs to be changed to make the reference updating of formulas in the clipboard simply follow all rules for moved content, where the moved content is the cell range to be shifted. Presently I have not found (nor searched for) the relevant code, so I really wouldn't know if this change will be doable for me. I will put my findings in comments in this bug and only assign myself to this bug when I'm confident I can fix it.
I don't think I will be able to fix this. It will have to wait for someone who is familiar in this area of code.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
LO version 4.4.2.2 on Windows: problem as decribed in description and comment 9 is still present.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Reproduced problem as described in description with LO 5.0.5.2 on Windows7
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Reproduced problem as described in description with LO 5.3.3.2 on Windows7
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Reproduced problem as described in description with LO 6.0.5.2 on Windows10
Dear Winfried Donkers, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #21) LO version 6.2.4.2-64bit on Windows 10: problem as described in description and comment 9 is still present.
Question here is whether this is a bug and should behavior that has some logic be changed. In cases like this one, I'm not in favor of changing behavior, but I'd rather see an option to choose behavior. So this should IMHO be an enhancement. We need UX decision.
(In reply to Winfried Donkers from comment #22) > LO version 6.2.4.2-64bit on Windows 10: problem as described in description > and comment 9 is still present. Eike replied in c10. When I shift-paste the reference is updated to F, which makes sense. Shift first (and update references), paste after. So WFM, in my opinion.
No further input, so closing as WFM.