Created attachment 49387 [details] This is a sample spreadsheet with instructions to reproduce the issue. This "bug" stems from the discussion in <a href=https://bugs.freedesktop.org/show_bug.cgi?id=37230>bug 37230</a>. It's not clear if this is a functionality issue or a true bug, but here is the logic: Start with a blank spreadsheet, or one with some columns of data in it (a sample is attached). Click on a cell, any cell. Clicking on an arrow key on the keyboard moves the selected cell in the direction of the arrow. This is normal navigation of the spreadsheet and works as it should. Now, select a cell within a block of contiguous cells. Ctrl-click an arrow-key (cmd-click on the mac), this moves the selected cell to the start or end of the next block of text, or the end of the spreadsheet if it finds no block. This also is working as it should. This part is the "bug": Select a cell and shift-click an arrow key. This highlights multiple cells, but you'll notice that the selected cell has not moved! The original cell you clicked on is still selected (i.e., the cell is surrounded by a thick black line), which is inconsistent with the behavior of other arrow-key actions. Shift-ctrl-arrow key also does not move the selected cell. The change that I'm suggesting is that shift-clicking and shift-ctrl-clicking arrow keys should produce the same behavior as ctrl-arrow keys and arrow keys by themselves, i.e., a change in the cell that is currently selected (surrounded by the heavy black line). The current behavior becomes problematic when trying to rapidly select multiple columns of text of different lengths. Since the selected cell doesn't move with the shift-arrow-clicks, ctrl-shift-clicking produces unexpected behavior, it moves to the start or end of the next contiguous block of text for the originally selected cell, rather than the next contiguous block of text of the cell to which the user has currently navigated using arrow keys. I've attempted to write a list instructions in the sample spreadsheet to demonstrate what I mean. Does this make any sense?? Thanks for your attention here, I know you guys probably have many more requests than time.
Reproduced on LibreOffice 3.4 340m1(Build:103) for OpenSuse Linux. I can reproduce the inconsistency and understand why it might be better to move the cell marker when using shift. ie, Select text in one column with CTRL, then you shift to the adjacent column and want to select all the data in that column as well. When you use CTRL, it does not work since the marker has not moved along.
This behavior is as expected. It's intentional that when expanding a selection, the current sell position does not move. This is in line with pretty much any other spreadsheet programs: Excel, Gnumeric, and Google Docs. So, I'm sorry to say this, but the current behavior, as far as I can see from your description, is by design.
I'm fortunate that version 3.3 of oo.org is still up and that uses consistent selection behavior over all of the arrow-key combinations and it looks like version 3.3.1 of libreoffice acts in this way too, although it's not supposed to be since the focus cell is not changing (whereas it is in oo.org). I guess I'll keep using 3.3 until I'm finally forced to upgrade, but my particular use of these spreadsheets pretty much requires being able to navigate in this way (arbitrarily long lists of imported columns of data on which I'm doing some operations in separate cells and then exporting the transformed data, all via the clipboard). I guess the future for me is all bash, awk, bc and gnuplot. Regardless, thanks for your responses on this and at least considering it, I really appreciate it!
Sure. Good luck with your future endeavors. Case closed.
wrong resolution type.
To be more like Excel, eh. Perhaps in future versions we can expect more Excel-like behavior to LibO Calc, i.e., support to virus prone VBA scripts, .Net, bugs, crashes, heavy weight bloat-ware, Windows and Mac only, and runs on Linux through Wine. Perhaps LibO will get a good funding from M$ to become M$Office test bed. Like OOo to Star. Or perhaps that is becoming already...or at least a target. Darn, sure "money changes everything".
No time for smart a$$.
*** This bug has been marked as a duplicate of bug 37230 ***