Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
5.7.1
-
Windows 10
-
f7980f4eda0ab2d7684357fd28b40bf6bbed260f (qtbase/5.11, 25.4.2018, 5.11.1)
Description
This is similar to QTBUG-57938 but rather less important; a given keyboard will only have either a Num+. key or a Num+, key, so it's not useful to define both shortcuts. Nonetheless this was reported by a user of our application (we had inadvertently left the English shortcut defined in the German version).
STEPS TO REPRODUCE
1. Build and run the attached application on Windows.
2. Connect a German keyboard and switch to the German keyboard layout in the OS.
3. Observe that there are two menu entries, one with shortcut 'Num+.' and one with shortcut 'Num+,'.
4. Ensure the Application Output is visible in Qt Creator.
5. Press the ',' key on the numeric keypad.
EXPECTED: The shortcut for Num+, is triggered.
ACTUAL: An ambiguous shortcut for Num+. is reported in the app output.
I tried to work out what was going on here; it seems as though the 'fallback' case in QWindowsKeyMapper is mapping the virtual code for this key (0x6E, VK_DECIMAL) to Qt::Key_Period, even though the keyboard layout correctly returns a comma. I couldn't really work out why this fallback was necessary.
Attachments
Issue Links
- relates to
-
QTBUG-67200 Windows: Alt + Shift +9 and '(' results Ambiguous shortcut overload
- Closed