## Problem statement I often start searching through a spreadsheet with Ctrl+F, and most of the time I cannot find anything because "Sorry Mario, the princess is in another castle, er, sheet." As it was decided that LibreOffice would not allow searching all sheets directly from the search toolbar (in bug #98270), I then have to "upgrade" my search to use the search-and-replace dialog (Ctrl+H), except that LibreOffice makes me waste my time re-typing my search query again. ## Proposed solution Instead, when calling the "Find and Replace" dialog from the find toolbar, either by hitting Ctrl+H or by clicking the magnifying glass icon button at the end of that toolbar, then the search dialog should be pre-filled with my existing search query from the find bar, in the same selection state as the find bar's searchentry was. --- P.s. / related: especially in a workflow where you are forcing me to "upgrade/escalate the search", please consider also remembering the "Search all sheets" setting's state (bug #58676) to save me some extra hoops jumping (related article: https://zachholman.com/posts/shit-work/ …)
Created attachment 195973 [details] Demonstration video Clarification: this is currently partially implemented, but not "always". It only works by pre-filling with the last search query that you typed "Enter" for (i.e. a launched and failed search query). It does not pre-fill with whatever you have currently typed (or corrected) in the Find bar's searchentry if you did not press Enter first. This attached video demonstration makes the issue clearer. --- Tested with: Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded
Hmm... can see some utility of allowing the search string to cross bounds--but *not* at the expense of again cross-contaminating the search configuration between the Find Toolbar and the Find and Replace (F&R) dialog. Still have bug 112270 to fully resolve. @Jim, what do you think. Could the exact use case of pre-populating F&R 'Find' field on opening the dialog with the typed entry (i.e. without executing the search) made from the Find Toolbar entered search text be done reliably?
Created attachment 196015 [details] demo of Writer quick find panel implemention of request I was able to make the Writer quick find panel Find and Replace button click behavior as such. Doing this for the find bar Find and Replace button seem not an easy hack. https://gerrit.libreoffice.org/c/core/+/172375
(In reply to Jim Raykowski from comment #3) > Created attachment 196015 [details] > demo of Writer quick find panel implemention of request > > I was able to make the Writer quick find panel Find and Replace button click > behavior as such. Cool! Thanks Jim > Doing this for the find bar Find and Replace button seem > not an easy hack. > Goes that way sometimes, thanks for looking. Assume no better for passing string from FB --> F&R dialog using <Ctrl>+H shortcut launch instead of the FB button? > https://gerrit.libreoffice.org/c/core/+/172375
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9f79c01035fb5851bcba1f8fc646437be84f7194 Related: tdf#162580 When upgrading from Find toolbar search to It will be available in 25.2.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.
Jim, is this bug solved? I tested on master and if I search for "test" with Ctrl+F, then Ctrl+H the term is moved in to "Find" field. So, seems ok for me. Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 662c6a6d70bab6b1a6ae8048457907be97f447ca CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
(In reply to BogdanB from comment #6) > Jim, is this bug solved? > > I tested on master and if I search for "test" with Ctrl+F, then Ctrl+H the > term is moved in to "Find" field. So, seems ok for me. > > Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community > Build ID: 662c6a6d70bab6b1a6ae8048457907be97f447ca > CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 > Locale: ro-RO (ro_RO.UTF-8); UI: en-US > Calc: threaded For the Ctrl+F find bar I still repro the behavior described in comment 2 and shown in the bug demonstration video. Possibly you missed to not do a search on the entered term before hitting Ctrl+H. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8d114edc1fe479edee486c3818dd458636ce33d3 CPU threads: 4; OS: Windows 11 X86_64 (10.0 build 22631); UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
> Possibly you missed to not do a search on the entered term before hitting > Ctrl+H. > Jeff mentioned "most of the time I cannot find anything because "Sorry Mario, the princess is in another castle, er, sheet.", so I thought is about searching before. Indeed, it is not working for a not searched term. Can we mark the bug as New based on the fact that it is somehow confirmed?
(In reply to BogdanB from comment #8) > Can we mark the bug as New based on the fact that it is somehow confirmed? I say yes. This seems like a bug to me. And it manifests with: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fbde63c9c689f91c150062023054b6cbe7b3ceaf CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: CL threaded Jim, if I've misunderstood the situation - please clarify/change status as appropriate. Also - the title is soooo long. And - it's a bug, not an enhancement request. Fixed that.
The patch committed above copies the query text from the sidebar Find deck/panel when the Find&Replace button in the toolbar is pressed. It doesn't work for Ctrl+H shortcut, yet. Below is a link to a patch that copies the query text to the Find&Replace dialog when Ctrl+H is pressed in the Find toolbar find text field control. Normally Ctrl+H toggles the Find&Replace dialog on and off. This patch makes the Find&Replace dialog not toggle off when Ctrl+H is pressed in the Find toolbar find text field control. It either opens the Find&Replace dialog and copies the query text to it or copies the query text to the already open dialog. The patch does not address copying the query text when the Find&Replace button is pressed in the Find toolbar. A possible way to make this work is to add the .uno:SearchDialog command directly to tbunosearchcontrollers.cxx instead of as a separate button as it is now. https://gerrit.libreoffice.org/c/core/+/193837
Created attachment 203885 [details] demonstration of Ctrl-H to copy query text from Find toolbar to Find&Replace dialog
(In reply to Jim Raykowski from comment #10) > The patch does not address copying the query text when the Find&Replace > button is pressed in the Find toolbar. A possible way to make this work is > to add the .uno:SearchDialog command directly to tbunosearchcontrollers.cxx > instead of as a separate button as it is now. Seems clicking the F&R magnifying glass button at the end of the Find toolbar already works as expected. For me, pressing it after searching up or down or with 'find all', it fills the F&R dialog with the query text from the Find toolbar.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef503a4abf51b6eeac26d80444b5d69a98674db5 tdf#162580 copy query text from Find toolbar to Find&Replace dialog It will be available in 26.2.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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/89ffec202ee7a21c1f9b1d5deebfceb7357de5cc related tdf#162580: copy query text from sidebar Find deck to F&R dialog It will be available in 26.2.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 #14) > Affected users are encouraged to test the fix and report feedback. Yep, think means to pass the search string from FB or the SB Find deck over to the F&R dialog Find field are available now. =-testing-= 20251117 TB103 nightly Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 620(Build:0) CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #15) > (In reply to Commit Notification from comment #14) > > > Affected users are encouraged to test the fix and report feedback. > > Yep, think means to pass the search string from FB or the SB Find deck over > to the F&R dialog Find field are available now. > Right, both the FB and SB Find deck should now pass the search string to the F&R dialog when the query text entry control has keyboard focus and Ctrl-H is pressed.
Verified with Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: f8224b9625c26a7c92a289573765d4a201678d68 CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Thanks, Jim. Nice improvement!