Description: In the Writer Find&Replace window, the keyboard shortcut ~r for Replace does not work; clicking Replace does. (The shortcut ~x does.) Steps to Reproduce: 1.open aaa.odt 2.^h: search for 'a', try replacing with 'b' 3.'a' found; hit ~r (alt r), or 'r'. Nothing happens. 4. Click Replace: 'a' becomes 'b', next 'a' found —as expected. Actual Results: see above Expected Results: see above Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 149698 [details] file with 3 'a'
I think, hitting 'r' just brings the focus to the Replace Button. You have to press Enter to replace 'a' with 'b'. So for me everything works as expected and NOTABUG. Please change it back to UNCONFIRMED with an explanation, if you disagree.
(In reply to Dieter Praas from comment #2) > I think, hitting 'r' just brings the focus to the Replace Button. You have > to press Enter to replace 'a' with 'b'. So for me everything works as > expected and NOTABUG. Please change it back to UNCONFIRMED with an > explanation, if you disagree. If one has to hit Enter after ~r, it's not a SHORTcut any longer! With other editors (Open Office, Notepad, Notepad++, SciTE), just hitting the key (r, or ~r) does the replacement and searches for next. Besides, the shortcut ~x is immediate, does not require the user to press Enter.
I confirm it with Version: 6.3.0.0.alpha0+ (x64) Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30 Locale: en-US (de_DE); UI-Language: en-US Calc: threaded
Click or <enter> while on the Replace button will perform the replacement. But action of the accelerator seems disconnected. It will toggle between the Replace button and the Find Next button--but not perform the replacement. Contrast that with the ~l for an "Replace All" action which applies correctly. On Windows 10 64-bit en-US (1803) with Version: 6.3.0.0.alpha0+ Build ID: 5fe551931d49a64ca4ea793a5016c098e41e84cd CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL
This happens because the r accelerator conflicts with the "Diacritic-sensitive" check boxes accelerator. Using a unique one for the latter box would solve this; for example s does not seem to be used. Also the accelerator for Comments checkbox and the Close button (c) also conflicts, causing the same problem.
I may confirm the issue for LO 6.3.0.4. Previous LO 6.2.5 accelerator worked fine
*** Bug 129281 has been marked as a duplicate of this bug. ***
s is assigned to "Search For" but that's invisible in current releases so the s could be reassigned to Diacritic-sensitive
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a39a107af190cac7105b1dafdd7ec088881e8da6 Resolves: tdf#123825 reassign mnemonic for Diacritic-sensitive It will be available in 7.1.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.
FWIW, I guess the micro-managed accelerators for every little checkbox could be removed, and just leave the accels assigned for the "important" ones and then the others would be auto-assigned to whatever characters are left over after the important ones get their assignment. Anyhow for the English case going forward r is just assigned the once.
VERIFIED FIXED with Version: 7.1.0.0.alpha0+ (x64) Build ID: 8c18cd6823ddf4ef5ba67801a84cee26c9b5a9a6 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded Caolán, thanks for fixing it!