Bug 159079

Summary: With NumLock off in Numpad, then with Alt pressed the Num Pad arrow keys should not operate
Product: LibreOffice Reporter: Alistair Saywell <saywellaj>
Component: LibreOfficeAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED FIXED    
Severity: enhancement CC: buzea.bogdan
Priority: medium    
Version: 6.4.7.2 release   
Hardware: All   
OS: Windows (All)   
See Also: https://bugs.documentfoundation.org/show_bug.cgi?id=156443
Whiteboard: target:24.8.0 target:24.2.1
Crash report or crash signature: Regression By:
Bug Depends on:    
Bug Blocks: 98259    

Description Alistair Saywell 2024-01-09 08:51:43 UTC
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.
Comment 1 ajlittoz 2024-01-09 09:03:09 UTC
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.
Comment 2 Alistair Saywell 2024-01-09 09:16:40 UTC
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.
Comment 3 Mike Kaganski 2024-01-09 15:36:27 UTC
Confirm.

Likely, the place to check / fix is ImplHandleKeyMsg in vcl/win/window/salframe.cxx
Comment 4 Mike Kaganski 2024-01-10 15:13:14 UTC
Will be fixed by https://gerrit.libreoffice.org/c/core/+/161891.
Comment 5 Commit Notification 2024-01-10 16:39:51 UTC
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.
Comment 6 Commit Notification 2024-01-12 18:31:40 UTC
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.