Description: Cell display and cell preview window do not match. Steps to Reproduce: 1. Open new LibreOffice Calc document 2. Write in any cell any character and follow it with space (example: "Something ") 3. Press enter to confirm cell 4. Append to that same cell character '°' (AltGr + 5) 5. Press space 6. In cell it is now displayed "Something °SUM(Število)", with "Število" being highlighter (selected) 7. "SUM(Število)" is not desired in this case so try to delete it by pressing backspace 8. In cell it is currently visible "Something °SUMŠtevilo)" and in cell preview window it is shown "Something °SUM()" Actual Results: In cell it is currently visible "Something °SUMŠtevilo)" and in cell preview window it is shown "Something °SUM()" Expected Results: I excpected that cell view and preview windows would match. Reproducible: Always User Profile Reset: Yes Additional Info: Note that I edited the cell in preview window. It appears that if editing cell directly problem doesn't occur. Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (sl_SI); UI: sl-SI Calc: CL threaded
So this SUM(Število) is just supposed to appear out of nowhere? I don't reproduce. What if you deactivate Tools - Options (LibreOffice - Preferences on macOS) - LibreOffice - View - Use Skia for all rendering? A screen recording would be nice, you can use something like https://obsproject.com/ Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Ok, now I get it. Alt+5 on the NumPad could insert some ASCII character, but it is also the shortcut for the Functions pane of the Sidebar (just like 1 to 4 for the other panes). I see that this can be distracting. For now, you could use another way: type the hexadecimal code for the character and press Alt+X. For ° it would be B0. You can discover the codes from Insert - Special Character. But bug 156443 says that Alt+NumPad is not really supported yet. Let's alert UX team.
*** Bug 158111 has been marked as a duplicate of this bug. ***
*** Bug 158201 has been marked as a duplicate of this bug. ***
When implemented the accelerators for Sidebar Decks were <Ctrl>+<Alt>+[1-9] as for bug 84502 Due to complaints of AltGr <==> <Ctrl>+<r-Alt> interference with localizations, the Sidebar Deck accelerators/shortcuts were changed to just <Alt>+[1-9] by Caolán for bug 151059 [1] Couldn't We restore the <Ctrl>+<Alt> but adjust the keysym mapping to adjust the MOD2 modifier to distinguish between l-Alt and r-Alt for continued AltGr os emulation? But gain more explicit control over the accelerator/shortcut assignments. Otherwise, LibreOffice is Unicode focused by HEX value including our <Alt>+X and Special Character Dialog/CharMap handling--are we really obliged to support MS ASCII/OEM "AltCode" [2] handling? IMHO past time to dump that legacy Win crud, which MS has deprecated. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/155831 [2] https://en.wikipedia.org/wiki/Alt_code
(In reply to V Stuart Foote from comment #5) > are we really obliged to > support MS ASCII/OEM "AltCode" [2] handling? Please be aware that users that need to insert characters that are not included in their keyboard layout might be using these type of shortcuts. One typical scenario is users inserting characters of other/multiple languages (such as accented letters/vowels while using a US keyboard). When such needs are sporadic, other methods of inserting foreign characters are available. OTOH, when such needs are (very) frequent, users might even remember/memorize such keyboard shortcuts.
We discussed the topic in the design meeting. An idea to solve the problem is to use alt+shift+<num>. Or to remove the default shortcuts, and make it available for customization. This means a considerable effort and could be detrimental to a11y (no default). Sidenote: ctrl+alt+<num> is available for customization but should not.
*** Bug 158351 has been marked as a duplicate of this bug. ***
Mike K. proposes a potential numberpad scancode solution in see also bug 156443
*** Bug 158490 has been marked as a duplicate of this bug. ***
If I can use alt codes in the REST of the windows interface across multiple programs, I should be able to in LibreOffice, and, until recently, I COULD. Restore this functionality.
I always thought based on Windows issues cropping up that weren't on Linxus and devs at Document Foundation were completely biased against windows, and now I know... "IMHO past time to dump that legacy Win crud, which MS has deprecated."
I'm not seeing deprecation for alt codes in Windows. https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features Was there a particular source that you were reading? Windows.Crud.Com?
(In reply to xordevoreaux from comment #13) > I'm not seeing deprecation for alt codes in Windows. > > https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features > > Was there a particular source that you were reading? > > Windows.Crud.Com? The Wikipedia article gives the history [1]. Deprecated when Microsoft implemented the "EnableHexNumpad" registry string value and opened the entire Unicode for use moving MS Windows beyond limitations of localized code pages. Nothing biased against Windows, the project is cross platform and Unicode centric with extensive ICU lib based handling rather than native Windows os/DE. Our Unicode toggle (<Alt>+x) and Special Character dialog provide consistent UI cross platform. =-ref-= [1] https://en.wikipedia.org/wiki/Alt_code
I always wonder, which part of the body do people use for reading and thinking, when they read a topic like this, with several different people openly sharing their opinions, but there are things like comment 9, pointing to the solution to make Alt codes work; and most important - comment 7, which is the *official* notice from the design meeting, where the decision was to do some changes *to fix this*. And then these people claim bullshit like "I always thought based on Windows issues cropping up that weren't on Linxus and devs at Document Foundation were completely biased against windows, and now I know...".
*** Bug 158772 has been marked as a duplicate of this bug. ***
*** Bug 158786 has been marked as a duplicate of this bug. ***
The bug is much easier to reproduce in Writer, see bug 158786
The amount of dupes will keep increasing with time, because the method is very popular (and certainly not deprecated from the POV of users) in certain cases as mentioned in comment 6. Since these popular shortcuts were ignored when the conflicting shortcuts were introduced, we could infer that: * newly proposed (or changes of) shortcuts in LO are not evaluated as consciously/deeply/broadly as they might need to; and * knowledge or awareness of these specific (popular) shortcuts is/was not (completely) understood nor investigated nor tested (as they should, at least once). So, FYI and JIC: * The relevant shortcuts (in MS Windows at least) are (exclusively): [ALT]+[Numbers in the Numeric Pad] * Regarding the amount of digits for the shortcuts, using 3 digits (from the NumPad) is not the same as using 4 digits (from the NumPad). For instance, [ALT]+([1]-[2]-[3]) does not introduce the same character as [ALT]+([0]-[1]-[2]-[3]). * Numbers in the upper row of the normal keyboard are _not_ equivalent in terms of these shortcuts * [AltGr] is _not_ equivalent in terms of these shortcuts; they work with [ALT] * Other combination of special keys are not supposed to be equivalent, but some software aimed at accessibility-needs might interpret some other combination of keys, or some "gesture", as equivalent to [ALT]. Other software (or hardware) might use some alternative keys in order to "fake" the Numeric Pad when the real keyboard does not include a real one. * Regarding the amount of digits for the shortcuts, using 3 digits (from the NumPad) is not the same as using 4 digits (from the NumPad). For instance, [ALT]+([1]-[2]-[3]) does not introduce the same character as [ALT]+([0]-[1]-[2]-[3]).
@Mike's suggestion in bug 156443 of logging the key input between <Alt>'s KEYDOWN and KEYUP and parsing that value would allow continued handling of the SB shortcuts as <Alt>+[1-9], and to keep the MS Win Alt codes, and likewise the extended Unicode NumPad Alt codes with "EnableHexNumpad" Windows registry enabled.
(In reply to V Stuart Foote from comment #21) > @Mike's suggestion in bug 156443 of logging the key input between <Alt>'s > KEYDOWN and KEYUP and parsing that value would allow continued handling of > the SB shortcuts as <Alt>+[1-9], and to keep the MS Win Alt codes, and > likewise the extended Unicode NumPad Alt codes with "EnableHexNumpad" > Windows registry enabled. Can Mike's suggestion distinguish between ALT+7 as a LibreOffice shortcut and ALT+7 as input for the bullet point sign "•" in Windows ? (see here: https://bugs.documentfoundation.org/show_bug.cgi?id=156443#c4 ) If not, then it doesn't seem like a good suggestion to me.
*** Bug 158829 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #14) > (In reply to xordevoreaux from comment #13) > > I'm not seeing deprecation for alt codes in Windows. > > […] > > The Wikipedia article gives the history [1]. > Deprecated […] > > [1] https://en.wikipedia.org/wiki/Alt_code I don't see anything about deprecation in this link. I agree with comment #20 > The amount of dupes will keep increasing with time, because the method is > very popular (and certainly not deprecated from the POV of users)
"component" should probably be changed from "Calc" to something broader (maybe "LibreOffice"??) since this bug is not limited to Calc but also affects Writer
*** Bug 158967 has been marked as a duplicate of this bug. ***
Often you are assigned to a different thread because the topic may be duplicate. The issue of “Alt+numbers” could possibly be solved in this way: Leave the convenient Alt+numbers function. Everyone who wants to choose special characters from a list is free to do so, likewise the input of unicodes. Let's see why "ctrl+F5" (official) and "Alt+1" open the attribute window even though "Alt+1" is not defined.
https://gerrit.libreoffice.org/c/core/+/161891 for tdf#156443 will fix this - by completely disabling Alt+NumPad shortcuts, allowing only Alt+Numbers from main keyboard area. Basically, what V Stuart Foote suggested (even though I disliked the idea initially). Please shout if the last point (disabling Alt+NumPad) is concerning.
Forgot to mention, that the change referenced above is Windows-specific. It will not affect any other OS.
Luckily only Windows is affected. But then I'm happy. Sarcasm doesn't really help, but it seems sensible to simply undo the program adjustments.
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.
(In reply to Commit Notification from comment #31) > > https://git.libreoffice.org/core/commit/ > 772da0f1aa6891a0b31d45d99a5978c65ed24e34 > > Affected users are encouraged to test the fix and report feedback. Both flavors of Microsoft NumPad ALT codes, the "OEM" (1 to 3 digit codepage) and "ASCII" (4,5 decimal digits matching the Unicode BMP) [1], are restored. While the <Alt>+[1-9] keyboard shortcuts remain available. Pretty deliberate distinction in place, so think the UI will be acceptable while retaining current customization. Thanks Mike! @Seth, seems this divergence between the Windows Numpad ALT codes (both the "OEM" and "ASCII" for Unicode BMP) and the SB deck's <Alt>+[1-9] shortcuts (Windows only) now will need some mention in help/documentation. =-Testing-= With TB-78 nightly 20230111 Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3cb1ed4339fc9aec414c0f112a69705a7a4d9cc6 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded =-ref-= [1] https://en.wikipedia.org/wiki/Alt_code
As a user I will wait until the next update. I had installed version 24.x.x in between and there were complications with the current version. 7.6.4.1. The 24.x.x was uninstalled again and I then had to reinstall the 7.6.4.1. See you later.
(In reply to V Stuart Foote from comment #32) > "ASCII" (4,5 decimal digits matching the Unicode BMP) Not only BMP. As explained in "Decimal input (Alt codes)" at [1], Alt + 120132 also works. [1] https://en.wikipedia.org/wiki/Unicode_input#Decimal_input_(Alt_codes)
(In reply to Mike Kaganski from comment #34) > (In reply to V Stuart Foote from comment #32) > > "ASCII" (4,5 decimal digits matching the Unicode BMP) > > Not only BMP. As explained in "Decimal input (Alt codes)" at [1], Alt + > 120132 also works. > > [1] https://en.wikipedia.org/wiki/Unicode_input#Decimal_input_(Alt_codes) @Mike, * Oh Cool! In addition to the whole BMP (not just the first 9999 as decimal), it also supports the full SMP--only rub is having to lookup/calculate the decimal values for the Unicode graphemes. Fortunately LibreOffices charmap in the "Special Character..." dialog does list both Hex and Decimal values. Still, imagine the additional work to support the Windows "EnableHexNumpad" would be appreciated as HEX is so much more efficient for entry. Also, I'd call this issue fixed, and worthy of back port. Double thanks!
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.
*** Bug 159055 has been marked as a duplicate of this bug. ***
*** Bug 159310 has been marked as a duplicate of this bug. ***
*** Bug 159226 has been marked as a duplicate of this bug. ***
*** Bug 159389 has been marked as a duplicate of this bug. ***
Whenever I enter accented characters via <alt>+num-pad, I always seem have to prefix the "number" with a zero (¿4 digit numbers?) I do NOT know if this is required or not. If this is so for all accented characters using this method, can the short-cut to the right side-bar only be triggered when the whole numerical entry is only a single digit (¿1 thru 9?) and all others are used to enter a character? Please advise. Thanks, Tracey
The fix at 24.2.1 and 24.8.0 splits the LibreOffice UI shortcuts assigned for SB decks from the MS Windows decimal Alt codes using the Numpad keys. The <Alt>+[1-9] (with keyboard numbers) assigned to the SB decks are now distinct from the <Alt>+[1-9] (with numpad numbers) restoring these MS "OEM" decimal Alt codes (those from 1-256): <Alt> + VK_NUMPAD1 --> ☺ WHITE SMILING FACE (Unicode U+263A) <Alt> + VK_NUMPAD2 --> ☻ BLACK SMILING FACE (Unicode U+263B) <Alt> + VK_NUMPAD3 --> ♥ BLACK HEART SUIT (Unicode U+2665) <Alt> + VK_NUMPAD4 --> ♦ BLACK DIAMOND SUIT (Unicode U+2666) <Alt> + VK_NUMPAD5 --> ♣ BLACK CLUB SUIT (Unicode U+2663) <Alt> + VK_NUMPAD6 --> ♠ BLACK SPADE SUIT (Unicode U+2660) <Alt> + VK_NUMPAD7 --> • BULLET (Unicode U+2022) <Alt> + VK_NUMPAD8 --> ◘ INVERSE BULLET (Unicode U+25D8) <Alt> + VK_NUMPAD9 --> ○ WHITE CIRCLE (Unicode U+25CB) Additionally the full range of MS decimal "OEM" Alt codes, as well as the decimal MS "ANSI" alt codes (e.g. those starting with "0") are available. With an enhancement that the entire Unicode Basic Multiplane (BMP) and Supplemental Multiplane (SMP) can be entered now via decimal Alt code. A future enhancement to handle Alt code entry via HEX and the MS Windows "EnableHEXNumpad" registry value has been suggested.
*** Bug 159524 has been marked as a duplicate of this bug. ***
writer: <alt>+nnnn(numpad) opens side-bar :-(, but does NOT enter character :-( calc: <alt>+nnnn(numpad) opens side-bar :-( ---AND--- enters character :-) #1 I would like the side-bar to NOT appear when entering a multi-digit number (both writer and calc fail). #2 I would like the nnnnn character to be entered (writer fails). Thanks, Tracey Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to Tracey from comment #44) > Version: 24.2.0.3 (X86_64) / LibreOffice Community Please read carefully the posts. The patch is expected to be part of 24.2.1 (emphasis on the 3rd number, "1", not "0"). Alternatively, test with a Dev version.
Thanks for the speedy fix (not that I've had a chance to test it). However, Comment 44 only mentions the locale as EN-US. Will I have to wait for a later release for it to work in British English?
(In reply to John van Someren from comment #46) >... Will I have to wait for a > later release for it to work in British English? No, just the 24.2.1.2 rc2 release build, week of ~19 Feb. The behavior is locale neutral, at 24.2.1 it will work with what ever Alt+Numpad the MS os/DE provides per locale.
*** Bug 159674 has been marked as a duplicate of this bug. ***
*** Bug 159798 has been marked as a duplicate of this bug. ***
*** Bug 160126 has been marked as a duplicate of this bug. ***
I recently updated to Windows 11 24.2.1.2 (x86) (portable apps version) and the bug is resolved.
Thanks. It's truly a real relief that it's working again.
Hello everyone, I just updated LibreOffice version 24.2.1.2 and the problem with Alt+PNum key combinations is working again. It's perfect, I thank the people who worked to make this possible again. Thank you, cordially, BOB.
Pierre F committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/e3d706d380c68fde45c71ca87213c0f1c1148455 add *MS insert ascii character* (tdf#158112)
*** Bug 160261 has been marked as a duplicate of this bug. ***
*** Bug 160520 has been marked as a duplicate of this bug. ***
*** Bug 160521 has been marked as a duplicate of this bug. ***