Created attachment 194803 [details] Example file from Excel 2016 Pressing Ctrl+A in Excel behaves differently from Calc: If the cursor selection is on a cell whose neighboring cells have any data, the rectangular cell range gets selected on first press of the combination. On second press of the combination the whole sheet is selected, just like in Calc, or if the selected cells neighbors are all empty. Copying this behavior would be useful for users switching from Excel. 1. Open attached file 2. Click on cell C5, press Ctrl+A -> The range C4:D6 gets selected. Press Ctrl+A again to get the whole sheet selected. 3. Click on cell G5, press Ctrl+A -> The range G4:H6 gets selected 4. Click on cell B11, press Ctrl+A -> The range B10:B12 gets selected 5. Click on cell F10, press Ctrl+A -> The range E8:F10 gets selected 6. Click on cell A1, press Ctrl+A -> The whole sheet is selected In Calc the whole sheet is selected on first press. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a2b6ce5d21b7f5c84ced8485f5af279f1bf8135f CPU threads: 14; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: default This worked always like this.
Created attachment 194804 [details] After selecting cell C4 in Excel and pressing Ctrl+A
Created attachment 194805 [details] After selecting cell F9 in Excel and press Ctrl+A
Created attachment 194806 [details] After selecting cell G5 in Excel and pressing Ctrl+A
Created attachment 194807 [details] After selecting cell B11 in Excel and pressing Ctrl+A
My opinion about this, based on my own tdf#153527 comment 9: If users use [CTRL]+[A], the initial selection should cover the adjacent active range of cells. The second immediate consecutive [CTRL]+[A] should select the entire _active_ range of cells. Only the third [CTRL]+[A] would select the entire worksheet. This of course should depend on whether a surrounding active range exists, and/or an entire active range of cells exists; when either of them is not relevant, the next "step" of the selection takes over. So, for instance, if the worksheet is entirely blank, the first [CTRL]+[A] immediately selects the entire worksheet. Alternatively, imitate/follow exactly what excel does regarding [CTRL]+[A]: "Select the current region if the worksheet contains data. Press a second time to select the current region and its summary rows. Press a third time to select the entire worksheet." <https://support.microsoft.com/en-us/office/keyboard-shortcuts-in-excel-1798d9d5-842a-42b8-9c99-9b7213f0040f>
Let's see what the UX/Design team thinks.
Sounds good but details are tricky. C4 => C4:D6 D6 => C4:D6 B3 => B3:D6 fill K5:L6 to have a range with empty cells around M7 => Excel = all in case of LTR, we should rather select K5:M7 G5 or H6 => G4:H6 E7 => B4:H10 D7:E7 => B4:H10 B12 => all In case of RTL the adjacent cells are accepted to the right. To put it together: the selection extends if cells contain data left/right or top/bottom (makes the feature independent from sheet direction). If the resulting selection has only one cell with content select all. If left/right and top/bottom are empty do select all. Meaning: H10 => all G7 => B4:H10 G8, G9 => B4:H10 (Excel does all for LTR)
Such cyclic handling of the <Ctrl>+A cell selection in calc would be functional. And following the MS selection sequence here seems reasonable for interoperability. Mike's ScTable::ApplyWithAllocation by template work for bug 153527 [1] seems to give us a framework to overload the <Ctrl>+A selection. Also we have precedent from Writer with our cyclic l-mouse click selection of text: word, sentence, paragraph. Though cyclic text selection in sc cells could use a tweak to bring it in line with Writer paragraph and tables. +1 =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/161441
The uno command for selecting the area of the current cell is .uno:SelectData. That is item "Select Data Area" in the Customize dialog. It has as default the shortcut key Strg + *(from NumPad). That is unhandy for notebooks without NumPad. We could add an additional shortcut key by default. What really missing is a way to select the bounding area of all cells that have content.
(In reply to V Stuart Foote from comment #8) > Also we have precedent from Writer with our cyclic l-mouse click selection > of text: word, sentence, paragraph. In Writer, we have a better precedent. If you have a table in Writer, and your cursor is in its cell, then the first Ctrl+A selects the whole cell (if it has any text); then, the next Ctrl+A selects the whole table (and then the same for any number of nested tables); then, if the table itself is in a section, the next Ctrl+A selects that section (and then the same for any number of nested sections); and the next Ctrl+A selects the whole document. So this idea of Ctrl+A selecting all of closest "fragment" is familiar and may be useful. I have no concerns about it.
(In reply to Regina Henschel from comment #9) > The uno command for selecting the area of the current cell is .uno:SelectData. That makes it an easyhack! Do .uno:SelectAll only for multi selections or if a prior .uno:SelectData returns only one cell.
Tentative patch at https://gerrit.libreoffice.org/c/core/+/169276
What about repeat-Ctrl+A behavior though?
(In reply to Eyal Rozenberg from comment #13) > What about repeat-Ctrl+A behavior though? In case of a multiselection ctrl+A selects all, and consequently the second ctrl+A does the same as before. I wonder if a) we should remove .uno:SelectData as it becomes obsolete (and ctrl+a is easy to reach) or b) we have to add an option to keep the current behavior (some macros may rely on SelectAll; had to add such step to a unit test). What do you think? (patch has passed all tests and is ready to submit)
(In reply to Heiko Tietze from comment #14) > > I wonder if > > a) we should remove .uno:SelectData as it becomes obsolete (and ctrl+a is > easy to reach) Keep the command and keep its current short-cut. Why should old users of LibreOffice and OpenOffice learn a new behavior only because we make it easier for people coming from MS Office? The current short-cut already exists in StarOffice 5.1. As .uno:SelectData exists already a long time, it is likely that it is used in macros. The associated slot id is used in the Navigator dialog for icon "Data Range".
While I think that allowing/assigning the "stepping selection" for [CTRL]+[A] can be useful, I am not in favor of blocking the prior usage. If a user wants (or needs) the older behavior, it should be available (e.g. by customizing the keyboard shortcuts). As for eliminating something because it has some keyboard shortcut alternative (or vice versa), I would think that users with accessibility problems would not like that, especially when it has been available in LO for a long time.
Heiko's WIP already includes an (expert) config for that. Having this config, it's trivial to provide a UI for that.
(In reply to Heiko Tietze from comment #14) > b) we have to add an option to keep the current behavior (some macros may > rely on SelectAll; had to add such step to a unit test). Please, do not remove the .uno:SelectData command... it is definitely used in macros. I myself use it frequently. The current Ctrl+* shortcut (.uno:SelectData) works very similarly (if not identically in LO and Excel) so this shoudln't change.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e932e2ab943a9941fcfc7073c9b6c11b982c2c4c Resolves tdf#161641 - Select data area before select all It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d9fee55c634b500f1d7d0edaa25cecfc276b0869 CPU threads: 14; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: default works like Excel. Thanks Heiko!