Description: I found and downgraded org.OpenOffice.Office.Common.FindReplaceRembemberdSearches from 10 to 1 in the advanced options. (The reason is that the current behaviour — where you Ctrl F search for X, then you open the search for Y and close it, then you open it and search for X again and close it; then when you open the search again it’s Y by default because it was the last recorded — breaks my workflow so many times, so I want to work around it. I would like to have by default the item last used, like all current software, not the last recorded in this list.) Anyway, this setting now remembers the last thing I searched in the the Find and Replace popup (Ctrl H). However, the bottom search (Ctrl F) doesn’t align with this setting and still uses the last 10 searches. N.B.: I mainly use Calc, but this problem should be general. Steps to Reproduce: 1. Set org.OpenOffice.Office.Common.FindReplaceRembemberdSearches = 1 2. Ctrl H, search for X 3. search for Y 4. Look in the drop‐down list for searches: only Y is listed. 5. Close the popup 6. Ctrl F, search for X 7. search for Y 8. Look in the drop‐down list for searches: your last searches are listed. Actual Results: In case of Ctrl H FindReplaceRembemberdSearches is used, in case of Ctrl F it is not. Inconsistent. Expected Results: The two drop‐down lists should be consistent and respect the FindReplaceRembemberdSearches parameter. Reproducible: Always User Profile Reset: No Additional Info: Since the « Other information » box is mandatory: If you have a solution to circumvent the odd behaviour where the search proposes you to reuse the last recorded item in that list, even if in the meantime you reused several other items from the same list, therefore make it reuse the last *used* search item, that would be so useful!
“Whiteboard: QA:needsComment” What other comment is needed from the reporter? I can’t find an explanation in the Whiteboard page. The steps are explained. The bug rather needs someone to fix it.
Tools - Options - LibreOffice - Advanced - Open Expert Configuration - search for FindReplaceRememberedSearches Reproduced. $ git grep -n FindReplaceRememberedSearches officecfg/registry/data/org/openoffice/Office/Common.xcu:476: <prop oor:name="FindReplaceRememberedSearches"> officecfg/registry/schema/org/openoffice/Office/Common.xcs:6007: <prop oor:name="FindReplaceRememberedSearches" oor:type="xs:int" oor:nillable="false"> svx/source/dialog/srchdlg.cxx:345: nRememberSize = officecfg::Office::Common::Misc::FindReplaceRememberedSearches::get(); Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 79e60bb93f69370f23010adb078b5a5de5a1e7b2 CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 6 April 2023
(In reply to maison from comment #1) > “Whiteboard: QA:needsComment” > What other comment is needed from the reporter? I can’t find an explanation > in the Whiteboard page. The steps are explained. The bug rather needs > someone to fix it. It needed a comment from QA.
So your ask is to have the 'FindReplaceRememberedSearches' count from the "Find and Replace" dialog apply to the Find bar? OK. @Jim, confirm the Find bar list box and Navigator's repeat use does not follow the count if changed, so assume its count is fixed, maybe the default 10? I looked but couldn't find where. But also the Find bar lb seems a bit chaotic as to entry handling on the list, e.g. which find strings make the lb, both while active, but also on relaunch in current session. Can if be made to honor the 'FindReplaceRememberedSearches' setting? But also maybe tighten up the lb logic?
(In reply to V Stuart Foote from comment #4) > @Jim, confirm the Find bar list box and Navigator's repeat use does not > follow the count if changed, so assume its count is fixed, maybe the default > 10? I looked but couldn't find where. svx/source/dialog/srchdlg.cxx SvxSearchDialog ctor //tdf#122322 nRememberSize = officecfg::Office::Common::Misc::FindReplaceRememberedSearches::get(); if (nRememberSize<1) nRememberSize = 1; //0 crashes with no results found svx/source/tbxctrls/tbunosearchcontrollers.cxx FindTextFieldControl::Remember_Impl if (nCount == REMEMBER_SIZE) m_xWidget->remove(REMEMBER_SIZE-1);
(In reply to Jim Raykowski from comment #5) > svx/source/dialog/srchdlg.cxx > SvxSearchDialog ctor > //tdf#122322 > nRememberSize = > officecfg::Office::Common::Misc::FindReplaceRememberedSearches::get(); > if (nRememberSize<1) > nRememberSize = 1; //0 crashes with no results found > > svx/source/tbxctrls/tbunosearchcontrollers.cxx > FindTextFieldControl::Remember_Impl > if (nCount == REMEMBER_SIZE) > m_xWidget->remove(REMEMBER_SIZE-1); Thanks Jim. Both look to use the same FindTextFieldControl() but manage their entries differently. And the 'Findbar' keeps its REMEMBER_SIZE fixed at 10 [1] when instantiated, and did not get assigned the same nRememberSize for the FindReplaceRememberedSearches handling that the Find and Replace dialog received [2] with some tweaks. Kind of seems like it should have. So that the 'Findbar' (also the selector in UI for the string the Navigator uses for repeat) work from the same array/stack of strings the 'Find and Replace' dialog does. @Heiko? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbunosearchcontrollers.cxx?a=true&r=9ddbce1e#76 [2] https://gerrit.libreoffice.org/c/core/+/67614/ for bug 122322
(In reply to V Stuart Foote from comment #6) > So that the 'Findbar' (also the selector > in UI for the string the Navigator uses for repeat) work from the same > array/stack of strings the 'Find and Replace' dialog does. Wouldn't expect this but obviously it is the fact. So I agree to apply the REMEMBER_SIZE to the quickfind as well. (In reply to maison from comment #0) > I would like to have by default the item last used, > like all current software, not the last recorded in this list.) Isn't it how it works. You get the last search entry but can pick one of the n last used from the dropdown. If you search for FOO and BAR on a rotating basis I don't know what program offers the previous search before the last. And I believe it's more common to repeat the last search anyway.
(In reply to Heiko Tietze from comment #7) > > (In reply to maison from comment #0) > > I would like to have by default the item last used, > > like all current software, not the last recorded in this list.) > Isn't it how it works. You get the last search entry but can pick one of the > n last used from the dropdown. If you search for FOO and BAR on a rotating > basis I don't know what program offers the previous search before the last. > And I believe it's more common to repeat the last search anyway. Sorry, your comment shows you still don’t make the distinction between the last recorded and the last used. Take a big spreadsheet where you want to browse “FindReplaceRememberedSearches not respected in quick find bar” one by one. When you encounter one of them, you realise you temporarily want to look for an occurrence of “abcde”. You did that then you want to go back to your main searches, but now every time you open the quick search bar, Calc stubbornly will want you to search only for abcde. Your main search is nuked and you have to remind it every time; as soon as you select it from the history and use it, close the search bar and open it again, it stubbornly comes back although you don’t want it any more (i.e. because you’ve been using “FindReplaceRememberedSearches not respected in quick find bar”). This behaviour is inconsistent with Excel (Excel always proposes to reuse the last used search) but also with Calc itself, since if you don’t open the quick search bar, but press Ctrl Shift F, it would indeed reuse the last used search term !
(In reply to maison from comment #8) > “FindReplaceRememberedSearches not respected in quick find bar” Thought you run into problem with the full search (ctrl+H). Search for 1, the close and reopen and search for 2, close and reopen etc. 1 and 2 alternate and you get the last search. This works as expected, hopefully. The request is to make the quickfind (ctrl+F) working similarly. It currently does not sort the list if a search item exists. In fact neither the full search does but it remembers the last search item. Something like 1,2,A,Z should become A,1,2,Z and 2,A,1,Z if you research for A and 2 subsequently. And the first item should be picked on show. Something for you, Andreas?
(In reply to Heiko Tietze from comment #9) > (In reply to maison from comment #8) > > “FindReplaceRememberedSearches not respected in quick find bar” > > Thought you run into problem with the full search (ctrl+H). Search for 1, > the close and reopen and search for 2, close and reopen etc. 1 and 2 > alternate and you get the last search. This works as expected, hopefully. Unfortunately it does not. That was my "the Find bar lb seems a bit chaotic as to entry handling on the list" from comment 4 ;-) > > The request is to make the quickfind (ctrl+F) working similarly. It > currently does not sort the list if a search item exists. In fact neither > the full search does but it remembers the last search item. I don't think that there is any requirement (nor is it the ask) to sort the entries on the listbox, just that the stack for the lb should *reliably* push the search onto the stack for reuse. The ask is to pare down the stack in response to the nRememberSize set via the 'FindReplaceRememberdSearches' expert config value (either default 10 or as set).
(In reply to Heiko Tietze from comment #9) > Thought you run into problem with the full search (ctrl+H). Search for 1, > the close and reopen and search for 2, close and reopen etc. 1 and 2 > alternate and you get the last search. This works as expected, hopefully. > > The request is to make the quickfind (ctrl+F) working similarly. It > currently does not sort the list if a search item exists. In fact neither > the full search does but it remembers the last search item. > > Something like 1,2,A,Z should become A,1,2,Z and 2,A,1,Z if you research for > A and 2 subsequently. And the first item should be picked on show. Indeed, here you point out the problem that the full search popup remembers the last used search, but the quick find toolbar doesn’t. This is another inconsistency between the two searches. I see no reason for the quick search to be stuck to the last recorded item and not reuse the last used item like the other one and it would probably benefit most users; that would be an improvement; it’s just that I didn’t fill an improvement request, but a bug report. So, if the developer makes the quick search bottom toolbar, the full search & replace popup and Ctrl Shift F coherent with each other, then respect! In that case we would rather describe it in a new bug report. Otherwise the bare minimum would be IMO that FindReplaceRememberedSearches applies to both search tools.
Proposed patch: https://gerrit.libreoffice.org/c/core/+/150273 Unfortunately, the UI test fails on the clang build and I have no idea why
For the history issue I would prefer a separate report since it can be tested in an UI test. I will submit this patch without the UI test because I have no idea why it fails on the unix clang build.
Thanks Andreas. I created Bug 154818 as an enhancement to pick the last quick find item used. Contributors are invited to add comments and ideas.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b8349ca053753bb0dc713933628a1575a70677d3 tdf#154269 - Respect FindReplaceRememberedSearches expert option in quick find It will be available in 7.6.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.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/11a25339abfb957ea51614b67bbff26cb606f3a2 tdf#154269 - Respect FindReplaceRememberedSearches: add unit test It will be available in 7.6.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.
I improved the UI test but it is still not perfect since it does not change the expert option. Somehow the build remembers the old search entries and I don't know how to get rid of it.