-select any row(s) and cut -select destination and open paste special dialog -under 'shift cells', option 'Down' is disabled (should be 'Right') same for column(s) and option 'Right', where 'Down' should be disabled. Disabling an option is not done with copy/paste special, but same behaviour seems logical (rows cannot be shifted right, nor can column be shifted down). Behaviour the same with version 3.5 (sources of 24 October 2011)
LibO version built from code downloaded 27 october 2011 no longer has this problem.
problematic behaviour is back in master!
That it worked some time was a bug. I will try to have a look at it.
Hi, The current behavior is definitely wrong. Here's an additional twist: - Select one or more rows and CUT them. - Insert one blank row above the destination row. - now select the destination row. - Click on paste special. - Now Shift Down works. Of course, the rows you just cut will remain blank so you have to then go and manually delete those rows. This functionality is quite a hindrance when you have to move large numbers of rows around, especially in long spreadsheets, where moving things around with the mouse isn't (gasp!) the most practical thing in the world.
Problem still present in version 3.6.0.4
And remains with: LibreOffice Version 3.6.3.1 (Build ID: f8fce0b) LibreOffice Version 3.7.0.0.alpha0+ (Build ID: bc63efc)
Confirmed solved in Version 3.6.4.3 (Build ID: 2ef5aff) Version 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0) Please Winfried can you confirm it is solved in newer versions. Thanks
Seems to be the same problem as "Bug 56098 - UI: 'Paste Special - Shift Cells' options availability not logical", where we have many more research. So I mark this one as a DUP @mariosv: You did that test in comment above on Raspberry Pi with self written experimental OS? We need to know your OS in such comments! As visible in Bug 56098 I still see the problem in the latest versions @all: Please feel free to reopen this Bug if you find evidence that we have an independent issue here. *** This bug has been marked as a duplicate of bug 56098 ***
(In reply to comment #7) > Confirmed solved in > Version 3.6.4.3 (Build ID: 2ef5aff) > Version 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0) > > Please Winfried can you confirm it is solved in newer versions. > Thanks @mariosv: problem still persists in version 3.6.4.3 (build 2ef5aff) on Windows (cannot test on master as I am building right now) I will put any new information under bug 56098
Created attachment 71913 [details] Screenshot showing the option selected. Hi Winfried, find attached screenshot showing the option selected. Win7x64 Ultimate Version 3.6.4.3 (Build ID: 2ef5aff)
Created attachment 71914 [details] Screenshot showing the option selected. Reattached as PNG.
(In reply to comment #11) > Created attachment 71914 [details] > Screenshot showing the option selected. > > Reattached as PNG. Hi mariosv, from your screenshot I suspect you _copied_ the row. I you cut it, the options look different.
Hi Winfried, you are right. Forgive me.
(In reply to comment #13) > Hi Winfried, you are right. > Forgive me. No problem, I'm glad that this unexpected behaviour has been explained now.