If only one cell is selected, the "Find & replace" dialogue always returns "Search key not found," when doing a simple "find", regardless of whether or not the search key is present in the cell.
-= To reproduce =-
Open a new spreadsheet (File -> New -> Spreadsheet)
In Cell A1, enter the following text (without quotes): "The quick brown fox jumps over the lazy dog"
Confirm text entry with ENTER
Select Cell A1 (the cell containing the text)
Open the "Find & replace" dialogue (Ctrl+F)
In the "search for" field, enter "quick"
1. Click on "Find"
The result is: "Search key not found."
2. Click on "Find all"
The cell is highlighted as expected
3. In the "replace with" field, enter "slow"
Click on "Replace"
The result is that the text gets replaced as expected:
"The slow brown fox jumps over the lazy dog"
-= End of reproduction =-
When doing a "find all" or "replace" search, the text is found. When doing a normal "find", the text is not found. I suspect that the behaviour in (1) was probably done deliberately, but I think it is inconsistent with the behaviour in (2) and (3).
I am running LibreOfficePortable 3.3.2 as downloaded from http://portableapps.com/apps/office/libreoffice_portable
(The "all languages" version)
Running on: Win7 64bit
Adding another condition for reproducing the problem
-> The highlighted cell has to be A1 as well
Candidate for easyhack?
(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?
> 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.
> 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]
patch for find and replace bug
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
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:
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]
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 126.96.36.199 on x86_64 Gentoo (linux).
Clicking on a single cell should be able to find and replace in the formula within that single cell.
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
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT:
- Update the version field
- Reply via email (please reply directly on the bug tracker)
- Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
Created attachment 122065 [details]
Bug is still present in
Build ID: Gentoo official package
Locale: en-US (en_US.UTF-8
i reproduced it. And this will be my first bug to fixed. So i am assigning to myself.
Although replace works.
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue