Version: 7.6.5.2 (X86_64) / LibreOffice Community Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b CPU threads: 16; OS: Linux 5.10; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Hi, in the Tools->Customize->Keyboard dialog, Ctrl+Shift+F6 is shown as reserved (gray, on both "LibreOffice" and "Writer" levels), but pressing Ctrl+Shift+F6 has no effect. Ctrl+Shift+F6 should be either available for user assignment or the intended hard-coded function (if there is one) should be fixed. BR, Tyler
I confirm it with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7c2ed9919d6d9d286d9062b91577d6bb2b7de8aa CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded cc: Design-Team for information about intended behaviour
Ctrl+Shift+F6 belongs to the accessibility shortcuts of LibreOffice and works as intended. If a sheet in Calc is divided into two parts (menu View -> Split Window), then the shortcut Ctrl+Shift+F6 gives access to the dividing line so that it can be moved with the arrow keys. BTW, combinations with F6 and F10 are often accessibility shortcuts.
(In reply to Regina Henschel from comment #2) > Ctrl+Shift+F6 belongs to the accessibility shortcuts of LibreOffice and > works as intended. > If a sheet in Calc is divided into two parts (menu View -> Split Window), > then the shortcut Ctrl+Shift+F6 gives access to the dividing line so that it > can be moved with the arrow keys. > > BTW, combinations with F6 and F10 are often accessibility shortcuts. Yes, but the Key_F6,Key_MOD1,Key_SHIFT is *not* a VCL reserved shortcut as listed in ReservedKeys[] array in svapp.cxx [1]; just Key_F6,Key_MOD1 is on the reserved list. Also, think the svapp.cxx only defines reserved two-key sequences, so why is the three-key sequence showing as reserved? Suspect a logic error (handling of both Key_SHIFT and Key_MOD1) in assigning it as reserved in acccfg.cxx [2]? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/vcl/source/app/svapp.cxx?r=e1c59fd5#99 and at #307 [2] https://opengrok.libreoffice.org/xref/core/cui/source/customize/acccfg.cxx?r=fa869ef6#1067
Reminds me on bug 146906 comment 23. And there is ScGridWindow::KeyInput() #ifdef DBG_UTIL if (rKeyCode.IsMod1() && rKeyCode.IsShift()) ... else if (rKeyCode.GetCode() == KEY_F6) It looks like a bug when reserved keys are ctrl+F6 and shift+f6 making ctrl+shift+f6 disabled too. Test-wise I commented out vcl::KeyCode(KEY_F6,KEY_MOD1) and could assign a command to ctrl+shift+f6. Ultimately we should not have any hard-coded key and show the actual assignment in the customization dialog.
(In reply to Heiko Tietze from comment #4) > Reminds me on bug 146906 comment 23. And there is > > ScGridWindow::KeyInput() > > #ifdef DBG_UTIL > > if (rKeyCode.IsMod1() && rKeyCode.IsShift()) > ... > else if (rKeyCode.GetCode() == KEY_F6) > > > It looks like a bug when reserved keys are ctrl+F6 and shift+f6 making > ctrl+shift+f6 disabled too. Test-wise I commented out > vcl::KeyCode(KEY_F6,KEY_MOD1) and could assign a command to ctrl+shift+f6. > > Ultimately we should not have any hard-coded key and show the actual > assignment in the customization dialog. OK, but there is a distinction to be made between shortcuts baked into UNO and other editshell based or VCL level shortcuts. Real issue is that the later shortcuts do not make it onto the customize dialog--even if non-editable. Current "reserved" mechanism seems dated.