Created attachment 178424 [details] searchslot Actual behaviour If the user applies a formatting to the search in the search and replace window (Cmd Shift F) and then later on makes just a search (in the same or in another document) with the search slot (Cmd F) (screenshot attached) the formatting applied to the search is retained, but the user is not warned resulting in unwanted results. Expected behaviour When user applies a formatting to the search in the search and replace window and then later on makes just a search (in the same or in another document) with the search slot, the user should be warned that formatting (which would be a plus) has been applied and be able to un-apply it. Reproduce Follow the steps in Actual behaviour
I understand this as a bug since no F&R settings should be taken into the quick find search. Steps to reproduce: * Insert dummy text like "He heard quiet steps behind him. He heard quiet steps behind him." * change the font color of one item like "He" in Dark Red 2. * Search per F&R for the term with the format font color = dark red 2 -> only one "He" will be found * close and open the quick find, search for "He" -> only the one "He" will be found that is colored Stuart, Cor: I remember discussions about this in the past. Anything I forgot to mention? Is it maybe a duplicate?
Hmm, confirm the issue. Format settings made in the <Ctrl>+H 'Find & Replace' dialog bleed over to subsequent searches from the <Ctrl>+F 'Find bar' Not sure that work on bug 62601 (and dupes) were really correctly resolved. But in addition to affecting the <Ctrl>+F 'Find bar' it also now impacts the Navigator's new 'Repeat search' mode. Which I guess should be expected--since the Navigator's instance is same framework as the Find bar's. Intent of bug 62601 was to keep the Find bar simple and light weight (effectively make use of transformations/regex to return generalized results) while Find & Replace would allow greater control. Would expect the Navigator's repeat search should take on the greater control of settings from F&R dialog, as it does. What is askew is that the Find bar's generalized search is responding to settings made in the F&R dialog. But secondly that there is no indication that settings from F&R are active. Given common framework (Find toolbar, and Navigator deck) We may not be able to make the Find bar truly a generalized search, but should then at least provide an indicator of F&R settings being applied. @Jim, any thoughts?
https://gerrit.libreoffice.org/c/core/+/131569 (In reply to V Stuart Foote from comment #2) > Hmm, confirm the issue. Format settings made in the <Ctrl>+H 'Find & > Replace' dialog bleed over to subsequent searches from the <Ctrl>+F 'Find > bar' The patch makes for only non formatted search from Find bar. > But in addition to affecting the <Ctrl>+F 'Find bar' it also now impacts the > Navigator's new 'Repeat search' mode. The patch makes 'Repeat search' follow the formatting of the previous search, so done after a formatted search from the F&R dialog it will also do a formatted search. When done after a search from the Find bar, made always a non formatted search with this patch, it will also do a non formatted search.
Hi everybody, could a warning that formatting is on such as - a background color (orange?) in the find bar plus - a check followed by - text summing up what formatting is being applied be a solution that keeps current improvements, but makes applied changes to the search field visible? Users would then be able to uncheck the check and the background color would go back to white for ex.
Alternatively the search and replace window and the find tab could work independently: the former would retain the applied changes, while the latter would only perform simple searches, without inheriting the formatting of the former.
(In reply to Anduril from comment #6) > Alternatively the search and replace window and the find tab could work > independently: the former would retain the applied changes, while the latter > would only perform simple searches, without inheriting the formatting of the > former. That's exactly what the patch does :) I've been trying to figure out why it fails a uitest on the remote build but not local :(
(In reply to Jim Raykowski from comment #7) > (In reply to Anduril from comment #6) > > Alternatively the search and replace window and the find tab could work > > independently: the former would retain the applied changes, while the latter > > would only perform simple searches, without inheriting the formatting of the > > former. > https://wordle-unlimited.io > That's exactly what the patch does :) > > I've been trying to figure out why it fails a uitest on the remote build but > not local :( You can test the patch by following instructions given here: https://wiki.documentfoundation.org/Testing_Daily_Builds
I'll read your writing more frequently, I swear. I'd love for you to join me in playing the video game https://slopegame.online that I just discovered when you have some free time.
(In response to Anduril's comment #6) Alternatively, the search and replace window and the find tab might function independently: the former would preserve the applied modifications, while the latter would just do simple searches, without inheriting the former's formatting. That is precisely what the patch does: https://idlebreakout.io/ I've been attempting to find out why an uitest fails on the remote build but not on the local.
(In reply to Jim Raykowski from comment #7) Thanks Jim Raykowski for explaining. This solution is just perfect!
great. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.clash-games.com
I spent many hours challenging myself and improving my https://retro-bowl.io/drift-hunters skills in this game.