I just upgraded Office Libre to 5.0.6.3, the most current version and after that my right ALT key no longer works - meaning it won't activate the menu shortcuts. The left ALT key works in Office Libre and the right ALT key works in other apps like FireFox.
Confirmed with US keyboard layout (where both Alts behave the same way). Right Alt+F opens File menu in 5.0.0.5, but prints an "f" character in 5.0.5.2. Still there in daily master build (0325b22a2a2b537a71f53b7c5d3e6c13fef68911). There was a keyboard shortcut-related commit between 5.0.3 and 5.0.4 (bug 95761), which might be related. Juergen?
On Windows 10 Pro 64-bit en-US with Version: 5.0.6.3 (x64) Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa Locale: en-US (en_US) Yes, see the same behavior continuing through 5.2.0.1 and in the 5.3.0alpha0+ builds of master. Accelerators are bound to the Left <alt> key as expected. But the Right <alt> key is not being processed the same. Right <alt> will toggle to the Main menu and back to document canvas (as F10 does)--but it does not get linked to form expected accelerators. And in addition accelerators not picking up the key for menu/toolbar navigation--the new <Alt>+x Unicode toggle also does not work with the Right <alt> key.
Hi Aron, V Stuart, the main problem of my patch is, it must be in dependency of the language. In some language (german) the right ALT = ALTGR for a third key-stuff, but in other language (english) exist not a different between this ALT-keys. The RIGHT-ALT+CTRL it is the same when press the ALTGR-Key, and without my Patch the HOT-Key combination of ALT-CTRL was not possible for the third key-stuff-keys. But at the moment we have no info if the Language with ALTGR or not. juergen
Hi Juergen, This seems to be a complex topic. I read the hint the other day that Ctrl+Alt shortcut modifier should preferably be avoided in Windows [1], and while I don't know how much of a problem reducing the amount of available shortcuts would be, it would save us from a lot of headache in the Alt-AltGr area. Would it be worth considering? It kind of feels that no matter what kind of workaround is implemented, something will always be off... Though in this case possibly checking whether VK_CONTROL was actually indicated to be pressed in the VK_RMENU IF clause, and ORing KEY_MOD2 if it wasn't, might solve this particular issue, because the right Alt key is never passed through. I kind of wonder how AltGr-modified keys still happen to work, but I don't know the code. [1] https://blogs.msdn.microsoft.com/oldnewthing/20040329-00/?p=40003
Created attachment 132739 [details] This problem also occurs in Calc for the Right Alt Key This bug is present on two Windows 10 x64 laptops, one a Dell with consolidated keyboardand the other a Toshiba with a ful keyboard. The attached spreadsheet, cell A1, is an example of what you get when you try to use the right Alt Key on either laptop.
Suspected commit confirmed using bibisect repo bibisect-win32-5.1. https://cgit.freedesktop.org/libreoffice/core/commit/?id=3ac9942c624cb627c8b09122498b45b05cf455f6 author Juergen Funk <juergen.funk_ml@cib.de> 2015-11-12 09:50:59 (GMT) committer Caolán McNamara <caolanm@redhat.com> 2015-11-12 14:14:32 (GMT) "tdf#95761 All Hotkeys with CTRL+ALT+ not worked"
it seems like a dupe of bug 97908 *** This bug has been marked as a duplicate of bug 97908 ***
I switched from Office Libre back to Open Office and it had the same problem (shared code base probably). However, in the most recent Windows 10 update (1703 (OS Build 15063.726)), the right ALT+E key combo starting working like before (i.e. correctly - opens the Edit menu). I see Microsoft has hidden their OS version - no longer under My Computer>Properties. In cmd window, need to type winver.