In Windows only Alt+code enters special character, e.g. Alt+0241 enters ñ. These Alt codes are at the top of the list when searching the internet on how to enter special characters. If NumLock is turned off in the Number Pad then the mouse keys are activated so 4 moves the cursor left. However, in LibreOffice the Alt+code is also still active so the inserted character is moved one place to the left. Using the code above, Espñaol is entered when Español was intended. Microsoft Word does not insert Alt+Numpad characters without NumLock; Alt also disables arrow movement. Microsoft Wordpad does insert the Alt+Numpad characters and also disables arrow movement. LibreOffice should do one of these, my preference being to emulate Wordpad as that might provide an easy workaround for https://bugs.documentfoundation.org/show_bug.cgi?id=158112 This issue arose from https://ask.libreoffice.org/t/special-characters-inserting-out-of-order-as-i-type/100378/11 I entered 6.4.7.2 as the earliest affected version because that is the earliest version I have tested.
Since the feature is Windows-only, isn't it a bug in Windows OS? Who handles the combination Alt+keypad_num? OS or application? If it is OS, keycodes corresponding to Alt and associated (numeric) key should not be passed to application until the full character encoding has been parsed and translated. Anyway, fixing this anomalous behaviour should have no impact on other OSes, notably it should not prevent assigning user shortcuts with Alt+keypad_num, whether or not NumLock is set.
The recent change (7.6.2.1) to apply LibreOffice UI shortcuts with Alt+single digit shows that the program can override the OS shortcut. Those Alt+single digit shortcuts override the hard-coded Windows shortcuts for Alt+0 to 9 of ○☺☻♥♦♣♠•◘ where they have been applied. It is not a bug in the OS, but rather it seems a choice for the program. LibreOffice has chosen both options of moving the cursor and inserting the character giving a worse result for the user than just choosing one.
Confirm. Likely, the place to check / fix is ImplHandleKeyMsg in vcl/win/window/salframe.cxx
Will be fixed by https://gerrit.libreoffice.org/c/core/+/161891.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/772da0f1aa6891a0b31d45d99a5978c65ed24e34 tdf#156443, tdf#159079, tdf#158112: support Windows Alt codes >=256 It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/45023ae9619cdc4332afb8f743d1695a23e8d866 tdf#156443, tdf#159079, tdf#158112: support Windows Alt codes >=256 It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.