| Summary: | "Find & replace" does not search single cell | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Stephan Zietsman <sziets> |
| Component: | Spreadsheet | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | caleb.hyde, cno, mhstlibo, sziets, sziets, turtle, vuhung16plus |
| Version: | 3.3.2 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=38430 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | patch for find and replace bug | ||
|
Description
Stephan Zietsman
2011-05-03 06:35:10 UTC
Adding another condition for reproducing the problem -> The highlighted cell has to be A1 as well Candidate for easyhack? Source: http://opengrok.libreoffice.org/xref/calc/sc/source/ui/view/viewfun2.cxx#1764 (where the error is thrown - most probably the range for search is set wrongly) (In reply to comment #1) > Adding another condition for reproducing the problem > -> The highlighted cell has to be A1 as well Muthu, I'm not sure what you mean. In the reproduction instructions it mentions "Select Cell A1 (the cell containing the text)". That line is mentioned just before "Open the "Find & replace" dialogue (Ctrl+F)". Did you just miss that, or are you referring to something else? (In reply to comment #0) > Select Cell A1 (the cell containing the text) when I actually *select* the cell (ctrl-click or shift-click, or increase/decrease selection) the find/replace simply does work. Can you pls check this? Thanks, Cor > when I actually *select* the cell (ctrl-click or shift-click, or > increase/decrease selection) the find/replace simply does work. To clarify what I mean by "select": I mean simply click on the cell (not ctrl+click or shift+click). I.e. the cell is surrounded by a thick border but is not "highlighted" with blue. However, even if the Cell A1 is both selected (thick border) and highlighted (light blue fill) the pop-up occurs as described ("Search key not found"). What version of LibO are you using? I apologise if my terminology is/was incorrect. @Muthu > The highlighted cell has to be A1 as well I think I now understand what you mean, Muthu. It seems that when the procedure is performed with another cell, the find function works as expected. I.e. if all of the references to "Cell A1" in my original post are replaced with, say, "Cell B1", then there is no "Search key not found" pop-up. (In reply to comment #4) > To clarify what I mean by "select": I mean simply click on the cell (not > ctrl+click or shift+click). I.e. the cell is surrounded by a thick border but > is not "highlighted" with blue. OK, then that's a difference with my test. > However, even if the Cell A1 is both selected > (thick border) and highlighted (light blue fill) the pop-up occurs as described > ("Search key not found"). What version of LibO are you using? same effect in 3.3.2 and 340beta5 > I apologise if my terminology is/was incorrect. No problem. Also if the terminology might be 'incorrect': if you perform an action that you expect to have a certain result, there at least is a UX issue. One solution might be that the option "selection only" is grayed out when there is no real selection. (Which is another usability improvement for the F&R dialogue which - in itself - is a great tool) Actually it does not seem to be a real bug, when you click out of A1 cell it finds the value in A1 well, so only the text shown there might be wrong, but the program's functionality is ok. (at least in versions 3.5 and 3.4) Created attachment 49770 [details] [review] patch for find and replace bug Hi, I've tried to hack in this bug. I see that when start to search, the nCol is increase (nCol++). If we put away that, the bug seem to be fixed. Not sure about other case. Please check :D Thanks mhst @mhst: When a range of cells is selected, and the range has multiple matches, hitting the Find button repeatedly should move from one match to the next, and so on. And your patch unfortunately breaks that use case. We deliberately skip the current cell for this particular purpose. So, to fix this, we need to somehow add special case where the selection contains only one cell. But then, if the current cell contains the match, and you are already looking at the match in the current cell position, why bother using the Find dialog in the first place? I'm just curious. > But then, if the current cell contains the match, and you are already looking > at the match in the current cell position, why bother using the Find dialog in > the first place? I'm just curious. I agree that it's not obvious why you would want to do it, so I will explain my use case: Let's say Cell A1 contains a fairly large formula/text, which contains the word "quick" about 5 times. Now I want to change "quick" to "slow" by using find & replace. In the "Search for" field, I type "quick". In the "Replace with" field, I type "slow". Before I press replace, I want to confirm that the correct reference will be replaced (A2 also contains "quick", which I don't want replaced). If I press "find", it will go to Cell A2. But if, instead of "find", I pressed "replace", it would replace the "quick" in Cell A1, not Cell A2. In the case described above, the "find" button behaves differently to the "replace" button. It is this discrepancy that drew my attention to the "bug". Sorry if my explanation is difficult to follow. If it's unclear, let me know. > So, to fix this, we need to somehow add special case where the selection > contains only one cell. Maybe have a look at the code for the "replace" button. I suspect it handles a single cell better than "find" does. [This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html An EasyHack should have been checked by developers and thus is confirmed regardless of age. Moving back to NEW from NEEDINFO again. Sorry for the hassle. any progress here ? :-) Deleted "Easyhack" from summary. Comment on attachment 49770 [details] [review] patch for find and replace bug according to comment #8 this patch should not be integrated, setting the "obsolete" flag so it does not turn up in bugzilla queries. I have encountered this bug on 4.0.0.2 on x86_64 Gentoo (linux). Clicking on a single cell should be able to find and replace in the formula within that single cell. Thanks adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details Seems to be nontrivial and stalled since 2011, removing EasyHack |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.