"Select to block margin" is a function that is, by default, mapped to <Control><Shift><ARROW>. It is used frequently in Calc to select large areas of data for copy/paste. LibreOffice has somehow severely damaged the "Select to block margin" function in Calc in two ways... The first problem is extremely easy to see: * Create a new spreadsheet. * Place cursor in A1 * Press <Control><Shift><Down>. The correct behavior would be that the cells from A1 through A1048576 would be selected and the display would show your cursor on A1048576. Instead, it selects all those cells but leaves you sitting in cell A1 and without changing your view at all. The second problem is much, much worse, and also harder to illustrate: * Create a new spreadsheet. * Type a list of labels in the first column for several rows (A1:A4 or so). For the test, you just need a few, but imagine it could be many thousands. * Now place your cursor on B1. * Put a formula in B1 that is =LEN(A1) * Now use <Control><c> to copy that formula and then move your cursor to B2. * Now we want to paste it down through the end of the data that exists in column A. So press and hold <Control><Shift>. While not letting go of <control><shift>, press <down> then <left> then <up>. Then let go of <Control> but continue holding <shift> and press <right>, then <enter>. The above method is a very common way to select areas for copying. But it is broken the moment the user presses <up> in the last line of the example above. Imagine if column A had 20,000 rows/cells of data. Without this functionality working, how would one copy a formula down the correct number of rows in column B to match the number of rows in column A? With this broken behavior, it could take hundreds of presses of the <page down> key while holding down <shift> trying to do what would otherwise take a few keystrokes. If these two problems are not clear from my description (the second one is hard to describe) I will try to come up with a sequence of annotated screenshots or something. I have tested that this is NOT broken in OpenOffice 3.2.1, nor in 3.4!! But it is broken in LibreOffice 3.5.7 and 4.0. This is a *HUGE* problem for my users. Big enough that I think we can't migrate from OpenOffice to LibreOffice and I just had to halt our rollout. Any serious spreadsheet user needs the ability to properly/quickly "select blocks to margins" of data.
Created attachment 75608 [details] Correct behavior illustration-odg Correct behavior illustration-odg
Created attachment 75609 [details] Correct behavior illustration-pdf Correct behavior illustration-pdf
Created attachment 75610 [details] Broken behavior illustration-odg Broken behavior illustration-odg
Created attachment 75611 [details] Broken behavior illustration-pdf Broken behavior illustration-pdf
After studying this problem with some coworkers, we determined what we think the root of the problem is- When you have select activated ( <shift> ) and move the cursor in any manner, the active cell is not moving, it is staying at the starting location of the selection process. This is a radically different (and broken) behavior. What is expected is that when you move during a selection, the active cell moves. Example One: * Click on cell A1 * Press and hold <shift> * Now press <right> * Note the active cell (the cell with the bold border outline) is still A1 and not B1 as it should be. You can also see the broken behavior with the mouse. Example Two: * Click on cell A1 * Drag out a selection with the mouse by holding down the first button. * Without letting go, notice that the active cell (the cell with the bold border outline) is still A1 and not the cell where the mouse cursor is/was located, as it should be. * When you let go of the mouse button, it is still showing the wrong cell as active (the start of the selection instead of the end). This above behavior explains why the <shift><control> behavior is also broken. When you activate <control>, it is looking at the data in the row or column of the *ACTIVE CELL*. Since the active cell is not moving properly with the keyboard arrow keys during a selection ( <shift> ), it is looking at the wrong column or row and responding the wrong way. We also found a workaround for the problem, it is a different way of trying to select regions of data, but it is too complex right now for me to try and explain without a visual attachment.
Another coworker pointed out that this will also break already previously recorded macros. Those macros would have expected the active cell to be at the end of a selection, not the beginning. It will also break macro compatibility between LibreOffice and OpenOffice.
I can confirm this bug using LibreOffice 3.4.3 on Windows XP and LibreOffice 3.6.5.2 on an up-to-date Arch Linux install. This is really bad. It completely changes the behavior of that function in a way that severely interrupts my workflow. It also would break any macro using any of the "select to XXX block margin" commands. Maybe I'm missing something, but I don't see how something so fundamental to basic spreadsheet navigation could change in such a dramatic way without drawing more attention.
New info as obtained by reading Bug 54679 I now speculate that the changes made to the cell indicator moving with Shift-arrow were intentional to better emulate Excel and Gnumeric. I can confirm that with Gnumeric, range selection does NOT move the active cell selected, which matches the changed/current LibreOffice 4 behavior. HOWEVER, Gnumeric (and presumably Excel) do NOT have a problem with Shift-Control-arrow behavior like LibreOffice 4.0.X does. This indicates someone probably made a haphazard change to the Shift-arrow behavior in LibreOffice without testing or considering that this would completely screw up Shift-Control-arrow behavior (which is described in detail in above postings). There is still no question this is a severe regression bug, but it does put a new twist on understanding how it happened to come about.
No change in LO 4.1. It is still very irritating for my users. :(
*** This bug has been marked as a duplicate of bug 37230 ***