https://bugs.documentfoundation.org/show_bug.cgi?id=156443
Bug ID: 156443
Summary: Windows: alt+numpad doesn't work for Unicode decimal
codes, like in WordPad/Word
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: difficultyInteresting, easyHack, skillCpp, skillVcl,
skillWindows
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
As described in Wikipedia [1], there is a way to use Alt + NumPad on Windows to
input Unicode characters. E.g., holding [Alt] and typing [3],[0],[4] on the
numpad, and releasing [Alt], produces "İ" (LATIN CAPITAL LETTER I WITH DOT
ABOVE, U+0130; decimal 304) in WordPad and in Word.
But in LibreOffice (and in notepad.exe), this produces "0", which is U+0030, or
decimal 48, which is 304 mod 256.
Despite we have a dedicated Alt+X function, converting hexadecimal codes to
characters and back, users still expect the Alt + numpad combination to work,
because it is mentioned in multiple places (e.g., fileformat.info [2] has a
"How to type in Microsoft Windows" entry), and questions arise, when this
doesn't work [3].
The keypresses described above produce this sequence of Windows messages
received by ImplSalYield in vcl/win/app/salinst.cxx:
WM_SYSKEYDOWN (VK_MENU with scancode 38)
WM_SYSKEYDOWN (VK_NUMPAD3 with scancode 51)
WM_SYSKEYUP (VK_NUMPAD3 with scancode 51)
WM_SYSKEYDOWN (VK_NUMPAD0 with scancode 52)
WM_SYSKEYUP (VK_NUMPAD0 with scancode 52)
WM_SYSKEYDOWN (VK_NUMPAD4 with scancode 4B)
WM_SYSKEYUP (VK_NUMPAD4 with scancode 4B)
WM_KEYUP (VK_MENU with scancode 38)
WM_CHAR ('0' with scancode 38)
Note that the last WM_CHAR is produced by TranslateMessage from the previous
Alt input, and it has the value that we use in the program (and which is bad).
This event sequence is identical also for WordPad, so there is no difference
here, only in the handling of the messages themselves.
The processing of the final WM_CHAR happens in ImplHandleKeyMsg in
vcl/win/window/salframe.cxx; there is a section starting with a comment telling
"only "free flying" WM_CHAR messages arrive here, that are created by typing an
ALT-NUMPAD combination".
It seems clear, that Windows itself doesn't provide the Unicode WM_CHAR data
for Alt input (even for Unicode windows, which LibreOffice windows are), and
WordPad / Word likely handle the SYSKEY* messages themselves to handle such
input. If we want to also handle it, we should do the following:
1. Log the SYSKEYDOWN/SYSKEYUP messages after initial Alt press SYSKEYDOWN
event, and if they are all from numpad, store their sequence (and drop it if
anything from non-numpad arrives).
2. When Alt key's WM_KEYUP arrives, analyze the stored sequence, and decide if
it's Unicode (i.e., if it starts with [0] or is greater than 255) or not.
3. If it's non-Unicode, just drop the sequence, and process the following
WM_CHAR as before.
4. If it was Unicode, then ignore the following WM_CHAR (having the scancode of
Alt), and instead, send an internal event with the proper Unicode character.
It is likely that ImplHandleKeyMsg is the best candidate for the change.
Note also, that there is a "EnableHexNumpad" Windows registry setting that
allows hex Alt entry [4]; the fix might also handle that (or a follow-up
enhancement could be filed for that).
[1] https://en.wikipedia.org/wiki/Unicode_input#Decimal_input
[2] https://www.fileformat.info/info/unicode/char/0130/index.htm
[3]
https://ask.libreoffice.org/t/lo-witer-strange-little-problem-capital-i-with-a-dot-on-top/93756/
[4] https://superuser.com/a/59458
--
You are receiving this mail because:
You are the assignee for the bug.
