Description: There is a command to select a contiguous area in calc (adjacent cells that are not empty). This command selects a rectangular block of cells starting from the active cell and going out in all directions until it hits whitespace or edge of sheet. The command can be executed with: Edit->Select->Select Data Area or by typing ctrl+* PROBLEM/BUG: The use of the menu option (with mouse) works fine, however trying to use the keyboard shortcut ctrl+* instead does nothing. (This shortcut, on US keyboard, is typed as ctrl+shift+8 in order to get ctrl+*) REPRODUCTION: Open or create a spreadsheet with data. Put the cursor somewhere within multiple rows and columns that are filled in. If you execute this command (using menu) it will select all contiguous cells that are non-empty around the cursor. If you try the same with keyboard shortcut it does nothing. ADDITIONAL INFO: -I have not (to my knowledge) changed any hotkey bindings in either Calc or elsewhere in windows to grab this key combination. -This is proven also by opening Excel on the same machine - the ctrl+* key command works as intended (Excel uses the same shortcut). If Windows or another program was hijacking this key combination then Excel wouldn't work either. -This key combination will not work on an entirely different computer running an older version of Calc v6.2.5.2 (x86) (I can't remember this key combination ever working on ANY version of Calc). Actual Results: see description Expected Results: see description Reproducible: Always User Profile Reset: No Additional Info: see description
Ctrl+Shift+* it's not the same for LibreOffice than Ctrl+*, this is why it doesn't work for you, test if it works with the * in a keyboard with the numeric keys. That happens also with other combinations in different languages. I think it has a no simple solution, because there are combinations making use of the shift key. IMO the best you can do it's assing your own combination, Menu/Tools/Customize - Keyboar.
I am not typing ctrl+shift+* as you believe. I am typing the correct key(s) of ctrl+* You are misinterpreting my additional information whereby I explained the exact keys I was pressing on a USA keyboard - ctrl+shift+8 - in order to result in the correct combination of ctrl+* This was only for the sake of clarity and completeness since there are different layouts worldwide. I also confirmed the correct keys are being pressed by stating it works in Excel, but not Calc. With your reply, however, I was able to determine the specifics of the bug. There are TWO '*' keys on SOME keyboards. There is the regular '*' (above the numerica '8' on USA keyboards) and then (on some keyboards) there is an additional on the keypad. I do not use and do not have a keypad. Most laptops or portable devices or touchscreen keyboards do not either. Therefore the vast majority of computing devices in the world do not have nor use an numeric keypad. They only enter the 'standard' keys on the main portion of they keyboard. On USA keyboard this means they enter the '*' above the 8. The bug therefore is this: Calc is ONLY accepting and working with ctrl+* when the asterisk is coming from a keypad. (I confirmed ths by pulling out an old keyboard and it DOES work in Calc once I type ctrl-* using numpad). Calc however is not also accepting and using '*' from the regular keyboard. This is the bug. FIX: for the command of "select data area" which is bound to ctrl+* key, Calc needs to be update to work with the following TWO keys: ctrl+* (from regular keyboard; currently this binding does not exist) ctrl+* (from number pad; this binding exists and works) Excel works with both. And the are both 'humanly' equivalent. They are only different to the computer and Calc because they have two different keycodes.
https://keycode.info/ When using this site the following two keys are specified: '*' (from above the '8' on a USA keyboard): 56, event.code=Digit8 '*' (from numpad on USA keyboard): 106, event.code=NumpadMultiply FIX: ctrl+(code56;Digit8) needs to be bound to Calc "select data area" command. ctrl+(code106;NumpadMultiply) is already bound to that command. Both keyboard entries look the same to a user. They only differ due to computer internal handling which is irrelevant to human user.
(EXCEL is already bound to both key combinations for the same command. This fix is simiply matching EXCEL and matching expected behavior from a user's view.)
Created attachment 181351 [details] keycode dialog screen in calc
Why has this bug been ignored? My reply shows it is a real bug and that the person commenting (that it wasnt and was intentional) was misinterpreting what I wrote and, sorry, simply wrong. Select area in Excel is CTRL+* (the asterisk on the "8" key of a US keyboard; the normal regular asterisk) Whereas in Librecalc CTRL+* does nothing and is broken. It has been mis-mapped to a DIFFERENT ASTERISK KEYCODE which is the asterisk on the number pad (as I have explained above). And the standard "8" asterisk is unassignable and unusable. If Librecalc wants to use the number pad asterisk *also* for 'select area' then fine, but the program should still work with the normal asterisk on the "8" key like Excel and not break compatibility. See attached image of the shortcuts in Calc (and again remember this is the wrong "*" asterisk that is being used/mapped and that there is no way in Calc to fix it or redefine any shortcuts to work with the normal asterisk on the "8" key.)
If somebody can point me towards the codebase which handles these keyboard shortcuts then I will attempt the fix and a pull request on my own. Waiting years to change a single number seems excessive.
(as an additional comment which is certainly obvious...most laptops, notebooks, chromebooks and keyboards do NOT naturally have a numberpad on them. So even executing the existing 'select area' isn't possible on a lot of devices because the keycode is wrong. When a laptop DOES have such a numberpad it will be by shifting the keyboard into a special mode and then using the letter keys like "UIOPJKLM..." etc. And then shifting the keyboard back out of the special numberpad mode. This should not be happening and the regular asterisk on the keyboard should be the one that is mapped. Whoever created the original Calc code just quickly typed with his right hand on HIS numberpad and said 'ok..well that's done..." and has permanently created a broken shortcut.)
"m.a.riosv", you are the only other CC on this bug. You read my bug report and then mis-interpreted it and said it wasn't a bug (when it is). Now this report just sits with no attention because of your bad dismissal. Can you please re-read the situation and correct your dismissal of this bug? Can you remove or fix what you said so that people know a problem exists?
Still an issue
I'm not going to change my opinion based in what you like or not, looks to me your comments a bit presumptuous from your side. You have set up yourself the bug as 'NEW', what is absolutely not fine, other one should do it. In 'Blocks' field, you can see it is connected to 'Shortcuts-Accelerators' bug. Now, if you can't solve it yourself, you must wait for a dev tanking care of it.
In Excel, the equivalent of LibreOffice's "Select Data Area" action is bound to Ctrl+a (or Command+a), so it does not require a numpad. In LibreOffice, Ctrl+a selects the entire sheet, which is pretty much never what you actually want to do; whatsmore, LibreOffice already has another shortcut for "Select All", as indicated by the shortcut hint in the menus: Shift+Ctrl+Space, which is the same as Excel's, and is logically consistent with the Ctrl+Space shortcut for selecting the column and the Shift+Space shortcut for selecting the row, too. Therefore, my recommendation would be for LibreOffice to change the default keyboard shortcut for "Select Data Area" to Ctrl+a, to match what Excel does and not require a numpad. I believe this solution would make everyone happy, and users who somehow wish to select the entire sheet can continue using Shift+Ctrl+Space, or clicking the top-left header area (between row "1" and column "A"). This could probably be considered an EasyHack? --- Further reference for comparison: * https://support.microsoft.com/en-us/office/keyboard-shortcuts-in-excel-1798d9d5-842a-42b8-9c99-9b7213f0040f#bkmk_selectwin for the standard selections-related shortcuts * https://ask.libreoffice.org/t/what-is-the-point-of-ctrl-a-select-all-in-calc/10040 where someone has been complaining about mostly the same thing.
Also: I'm no LibreOffice developer and I have no idea where this might be in LibreOffice's giant codebase, but if "casa" wants to propose a patch for it, you could probably find the relevant area of the code using "git grep", maybe searching for the keyboard shortcut itself or for the action's name from the menu ("Select Data Area")?
I think there might be some misunderstandings, and enhancements to make in this ticket. First, LibreOffice Calc's documentation, help files, wiki pages and *tool tips* should be as clear as possible when a keyboard shortcut refers to keys on the numeric keypad only. For example, in: https://help.libreoffice.org/7.5/en-US/text/scalc/04/01020000.html?&DbPAR=CALC&System=WIN we read: ---- Ctrl+ * where (*) is the multiplication sign on the numeric key pad Selects the data range that contains the cursor. A range is a contiguous cell range that contains data and is bounded by empty row and columns. ---- Interestingly enough, Calc's users can go to menu Tools > Customize > Keyboard and modify the default key bindings, but using: "['*_math_operator_key_but_not_from_numeric_pad']" is not available as a combination with either of [CTRL], [SHIFT], [ALT], or a combination between them. As said, in this customization dialog, the simple "Ctrl+ *" seems to be not explicit or clear enough regarding the "*" (among other) key(s) being from the numeric key pad exclusively. Having said that, you could assign: "[CTRL]+[SHIF]+[8]" (matching the US keyboard) to the command you want. So, in some sense, the request to be able to assign such keyboard combination is already available. Available, yes; being _default_ built-in, that's another thing. OTOH, there is still some _additional_ valid RFE here, the first one being improved documentation (e.g. tool tip) regarding the numeric key pad exclusivity when it is relevant. In Excel, there is (although, containing partially confusing or inaccurate info in some places): https://support.microsoft.com/en-us/office/keyboard-shortcuts-in-excel-1798d9d5-842a-42b8-9c99-9b7213f0040f in its section: "Keyboard shortcuts for making selections and performing actions" ---- Ctrl+A or Ctrl+Shift+Spacebar 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. ---- Such key binding seems useful, and a valid RFE for developers to evaluate, for either or both combinations. Additionally, is there some way of binding this in Tools > Customize > Keyboard? The ability to bind keys "depending on how many times the user presses the key combination" also seems a valid RFE (i.e. a third RFE; each should have its own ticket). Hoping some developer would comment here, so perhaps we would / should end up with three independent individual RFE tickets.