Download it now!
Bug 39438 - EDITING: shift-arrow key does not move selected cell
Summary: EDITING: shift-arrow key does not move selected cell
Status: RESOLVED DUPLICATE of bug 37230
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.4.1 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2011-07-21 08:16 UTC by Andrew G. Stack
Modified: 2013-07-31 23:45 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

This is a sample spreadsheet with instructions to reproduce the issue. (9.73 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-07-21 08:16 UTC, Andrew G. Stack

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew G. Stack 2011-07-21 08:16:10 UTC
Created attachment 49387 [details]
This is a sample spreadsheet with instructions to reproduce the issue.

This "bug" stems from the discussion in <a href=>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.
Comment 1 Jeffrey 2011-07-21 18:21:25 UTC
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.
Comment 2 Kohei Yoshida 2011-07-21 18:46:44 UTC
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.
Comment 3 Andrew G. Stack 2011-07-26 10:36:07 UTC
I'm fortunate that version 3.3 of 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  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!
Comment 4 Kohei Yoshida 2011-07-26 10:46:53 UTC
Sure.  Good luck with your future endeavors.  Case closed.
Comment 5 Kohei Yoshida 2011-07-26 10:53:13 UTC
wrong resolution type.
Comment 6 willy.bueno 2012-03-08 16:59:17 UTC
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".
Comment 7 Kohei Yoshida 2012-03-08 17:06:49 UTC
No time for smart a$$.
Comment 8 crxssi 2013-07-31 23:45:21 UTC

*** This bug has been marked as a duplicate of bug 37230 ***