In earlier versions of LibreOffice, you could use the range of an adjacent column to copy a range of formulas, using SHIFT and CTRL-down. Example of earlier correct behavior in LibreOffice 3.3.2: you have a range of values in A1:A1000. You wish to copy a formula (any formula) from B1 to B2:B1000. You copy the formula in B1 using CTRL-C, then move the cursor to B2, press SHIFT and (keeping SHIFT depressed), move the cursor to the left using the left arrow, then pressing CTRL-down. The range extends automatically to the cell A1000. You move the cursor (still depressing SHIFT) to B1000 using the right arrow key, then press CTRL-V to copy the formula. This behavior was highly useful for effortlessly copying formulas in large spreadsheets. This desirable behavior no longer works in LibreOffice 3.4.1 Instead, there is a slavish devotion to the way MS Excel works, which requires manually extending the range in B2 using the mouse or repeatedly pressing the down arrow. This is a real pain in large spreadsheets. (Try it). I tried enabling OpenOffice.org legacy behavior from the Tools/Optins/LibreOffice Calc/Compatibility menu to no avail. The irritating MS Excel-like behavior continued. !!!THIS IS REALLY AGGRAVATING TO A LONG-TERM OOo/LibreOffice USER!!! and makes LibreOffice just as useless for serious spreadsheet work as MS Excel. This is a MAJOR inconvenience. Please restore the previous functionality for copying using adjacent columns in LibreOffice 3.4.2
Failed to reproduce on LibreOffice 3.4 340m1(Build:103) for OpenSuse Linux. I opened LO calc and the SHIFT+CTRL+DOWN functionality works. However, when I try to copy a formula through such a large number of cells, LO hangs. But I would just like to point out that the functionality for effortlessly selecting cells work.
I observed the problem using LibreOffice 3.4.1 on Windows. I'll check on Ubuntu over the weekend.
I also found that bug on my computer (LO3.4.3, Ubuntu 11.04 , Gnome 2.31) Note that not only "Ctrl+Arrowkey" does not behave properly but "Ctrl+Arrowkey" does not work either (when editing a formula).
(In reply to comment #1) > Failed to reproduce on LibreOffice 3.4 340m1(Build:103) for OpenSuse Linux. > > I opened LO calc and the SHIFT+CTRL+DOWN functionality works. However, when I > try to copy a formula through such a large number of cells, LO hangs. But I > would just like to point out that the functionality for effortlessly selecting > cells work. The "Crtl+ArrowKey" command works well except when used while editing a formula. Did you try the "Crtl+ArrowKey" function when editing a formula ?
.
@Cor Nouws Does "." in your last comment (2011-10-14 08:40:24 PDT) means the bug was solved ? The bug status is still "NEW" isn't it ? Or does it mean enough information has been collected and no more comment should be added ?
Reported effects are more or less reproducible with "LibreOffice 3.4.4RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:402)]". We have a changed behavior in 3.4 compared to 3.3 (an OOo), but I doubt that it's a bug. I compared behavior of this version, OOo 3.1.1, "LibreOffice Portable 3.3.0 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:6 Tag 3.3.0.4)]", Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: d3d1481-3f8994a-2ba0a9f)]" (110909). Master seems to behave as 3.4. The first test with OOo 3.1.1 a) Tests with OOo, Steps to reproduce: 0. Preparations: Open new spreadsheet, type an "x" to A10, B11, C12, E14, F5, F6 11. Click A1 12. <Shift+4x-arrowright> (A1:A5 highlighted) 13. <Control+arrowdown> Cursor jumps to E14, what SEEMS in accordance with Help for that version: "...Moves the cursor to the bottom of the current data range". E14 is the most bottom cell containing data, empty column D will be ignored, what is a good solution, a jump to the bottom of the table is useless 14. Redo from 1, but with selected A1:F1 Now cursor will move to F5, that's not something with "Data Range", but simply the FIRST next cell containing Data below cursor. I would have expected cursor jumping to F14 of at least F5 New test with OOo 3.1.1 21. Click A1 22. <Shift+4x-arrowright> (A1:A5 highlighted) 23. <Shift+Control+arrowdown> Instep 3 marked range A1:E14, Cursor jumps to E14, A1:E14 selcted / highlighted, Cell Cursor E14 what SEEMS in accordance with Help for that version: "...Moves the cursor to the end of the current data range containig data". E14 is the most bottom cell containing data, empty column D will be ignored, what is a good solution, a jump to the bottom of the table is useless 24. Redo from 21, but with selected F1:A1 F1:A10 will become marked, I would have expected F1:A14, because Row 14 is the last one containing data. New test with OOo 3.1.1 31. Click E1 32. <Shift+4x-arrowleft> (A5:A1 highlighted) 33. <Control+arrowdown> Cursor Jumps to 'A10'. I would have expected A14 (Data Range), but cursor simply jumps to the next cell containing data. 34. Redo from 31, but with selected F1:A1 F1:A10 will become marked, I would have expected F1:A14, because Row 14 is the last one containing data. But not unexpeced after 21ff b) LibO 3.3.3 b1) Tests 11ff b1a) In step 13 jumps to A14: SEEMS Correct "End of range", but why column A? b1b In step 14 jumps to A5, means target column = where range started in step 11 target Row = the one of cell cursor position b2) Tests 21ff b2a) In step 23 marked range A1:E14, expected after b1, Cell cursor A1 b2b) Step 24 marked A1F5, expected after b1, b2a b3) Tests 31ff b3a) In step 33 marked range A1:E14, expected after b1, Cell cursor A1 b3b) Step 34 marked A1F10, expected after tests b c) LibO 3.4.4 c1) Tests 11ff c1a) In step 13 jumps to A10: Here Target row is defined in start range column, not in end range column, behavior different to OOo, LibO333 c1b In step 14 jumps to A10, Here Target row is defined in start range column, not in end range column, behavior different to OOo, LibO333 target Row = the one of cell cursor position c2) Tests 21ff c2a) In step 23 marked range A1:E10, expected after c1, Cell cursor A1 c2b) Step 24 marked A1F10, expected after c1, behavior different to OOo, LibO333 c3) Tests 31ff c3a) In step 33 marked range A1:E14, expected after b1, Cell cursor A1 behavior different to OOo, LibO333 c3b) Step 34 marked A1:F5, expected after tests c behavior different to OOo, LibO333 My conclusions -------------- OOo3.1.1 <Control+arrow> always reaches the next cell with contents in arrow direction from the current Cell Cursor. Useful in many cases, but IMHO not really consequent. LibO 3.3.3 <Control+arrow> always reaches the next cell with contents in arrow direction from the current Cell Cursor (as OOo). For Down-Example reached Column differs from OOo, not below cell cursor, but below begin of marked start range. Useful in many cases, but IMHO not really consequent. LibO 3.3.4 <Control+arrow> always reaches the next cell with contents in arrow direction from the START OF MARKED CELL RANGE. Differs from OOo and LibO333 For Down-Example reached Column differs from OOo, not below cell cursor, but below begin of marked start range. IMHO hehavior is not consistent in all cases I would prefer a solution that for our <Control+Arrowdown> Example, the most bottom line with contents will be reached @Lorieul In OOo Bugzilla it was not possible only to add oneself to CC, it was necessary to write a comment. Most of us have been used to comment a simple dot if nothing was to say. @Rmax Instead of mournful "EXCEL slavery" comments you should write down exact descriptions of your observation. "No longer works" is not a good description. Knowing all that behavior it's easy to find workarounds for your needs, for example 40. goto B2, <control+c> 41. <Control+Arrowdown> from A1 to A100 42. <arrowright> reaches B1000 43. <shift+control+arrowup> marks B1000:B1 44. <control+click> unselects B1 (not necessary) 45. <control+v> will paste formulas to B2:B1000. A little more work than with LibO333, but not terrible 50. or simpliy use the scroll slider? Mark and fill down?Faster and more secure than all other soulutions. 60. or if you do not want to use the mouse: 61. goto B2, <control+c> 62. <Control+Arrowdown> from A1 to A1000 63. <arrowright> reaches B1000 64. <shift+control+arrowup> marks B1000:B1 64. <shift+arrowdown> unselects B1 (not necessary) 65. <control+v> wil paste formulas to B2:B1000. Comparing number of all key press key release actions between LibO 3.3.3 and LibO 3.4.4 for your example (ontil past completed with<cnotrl+v> : 333: 14 344: 16 That seems not completely inacceptable @David: Help for this under "Shortcut Keys for Spreadsheets" is not very precise. For 'Ctrl+Down Arrow' I read: "Moves the cursor to the bottom edge of the current data range" . What ever "THE" current data range might be. I believe it means "Moves the cursor to the last row containing data below the current cursor position or marked cell row" Additionally all those details I found out nowhere are mentioned , I believe that should be improved in Help and Manual. @Kohei: I can't see any reason for urgent action, but currently I believe consistence is not optimum. But of course, there might be lots of cases for other use I did not examine until now?!
@Rainer: I'm sorry but Rmax is right, the new behavior in 3.4 is very annoying and anti-intuitive and it's also present in Ubuntu 11.10. It was so easy to Shift-Arrow to select the adjacent column and use Ctrl-Shift-Arrow to select the range. The new 3.4 behavior is just stupid and a big regression for such a common task in spŕeadsheets. I switched back to 3.3 and will stay there until this issue is solved. Or maybe go back to OpenOffice?
After 4 updates of the 3.4 version still no fix to the bug. I observed this same bug since OOo era sometimes when new version is released but fixed immediately in succeeding maintenance versions. However, it's very disappointing here in LibO this bug is never addressed. I retracted to 3.3.4 every time I try a new version of 3.4 when available because the bug is very annoying especially that I'm working with spreadsheets having thousands of rows. I wonder if it persist in 3.5, any testers here?
I can't believe this is defined as a feature rather than a bug in this thread: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=37230 That the old behavior was actually the bug????
Please do not use https://www.libreoffice.org/bugzilla/*, use https://bugs.freedesktop.org/* URLs instead.. Thanks Florian R.
(In reply to comment #0) > This is a MAJOR inconvenience. Please restore the previous functionality for > copying using adjacent columns in LibreOffice 3.4.2 Sorry I lack time to really dive in all technical issues and variations and what Excel should do when... It is not as handy as before, but the difference is small, IMO: Then it would be Ctrl+C Shft+> Ctrl+Shft+^ Shft+< Ctrl+V Now it is Ctrl+C > Ctrl+^ < Ctrl+Shft+v Ctrl+V Gradually I got used to it. It's one key stroke extra, and for people useing key's, that's a fraction of a second?
All those who ask "what's the difference?" clearly aren't heavy spreadsheet users. There is a difference and it's a big one. Perhaps someone should decide if Libreoffice aims to be a pretty office suite or a useful one. (In reply to comment #13) > (In reply to comment #0) > > This is a MAJOR inconvenience. Please restore the previous functionality for > > copying using adjacent columns in LibreOffice 3.4.2 > > Sorry I lack time to really dive in all technical issues and variations and > what Excel should do when... > It is not as handy as before, but the difference is small, IMO: > > Then it would be > Ctrl+C > Shft+> > Ctrl+Shft+^ > Shft+< > Ctrl+V > > Now it is > Ctrl+C > > > Ctrl+^ > < > Ctrl+Shft+v > Ctrl+V > > Gradually I got used to it. It's one key stroke extra, and for people useing > key's, that's a fraction of a second?
** 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.3.5 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) Thank you for your help! -- The LibreOffice QA Team
Hi, This has been fixed, by adding ... an extra option :) Tools > Options > Calc > General.. Use legacy cursor movement behaviour when selecting. See http://cgit.freedesktop.org/libreoffice/core/commit/?id=462b28770e4fa3dfa6fe4af71a6776cceb4c4640 Since I know the commit, I assume it can be set to fixed :) ?