Apache OpenOffice (AOO) Bugzilla – Issue 15501
Search and Replace "within selection" loses selection after one operation
Last modified: 2013-08-07 14:38:26 UTC
I saw this in 1.0.3 german Version WIN98SE and 1.1beta2 WIN98SE The problem can be reproduced by using attached document "searchreplace.sxw" and try to replace the leading "2" in all terms as "25M1" "22B9T" and so on Steps to reproduce 0. open document 1. select (with mouse) complete text 2. mouseclick on "search and Replace" - button 3. mark checkbox "Current selection only 4. Enter "2" into "Search for" 5. Enter "3" into "Replace with" 6. click "Find" ("2" in headline will be marked) 7. click "Find" again (because you do not want to replace this "2", but another one) expected: "2" of "32S2PF" should be marked actual: "2" in headline will remain marked The problem seems to be, that after step 6 we have a "new actual selection" for ["2" in headline] It is no problem to replace the leading "2" step by step with disabled checkbox. Rainer
Created attachment 6795 [details] Testfile
Reassigned to SBA
I used OOo 1.0.3.1 and Win2000: Confirmed! Additional bug: if you press "replace" instead of "search" then the first occurrence of the 2 is found and the whole selected text is replaced by 3. The entire selection is deleted and replaced by the "replace-string"
Confirmed (OOo 1.0.3.1, german / Win2K)
Confirmed (OOo 1.1 german / Win2K)
I think this is proved for WIN. Can anyone test with other OS? Rainer
Confirmed (OOo 1.1Beta2 German / Linux) Also the additional bug concerning "Replace" can be confirmed. "Replace all" seems to work.
-> ALL: PLEASE STOP anything that looks/sounds/reads like "Adding an additional bug" within another bug's description. We can not handle collective tasks. If you have an issue related to another one, then make some kind of cross-reference with the dependency field or within the description. But two problems must be in two tasks in the first place because only the developer of the respective code can tell. Thanks for your comprehension. That was for "in general". In this specific case, the described problems are indeed linked (not fixable at times because.... see below), but none of you could have known before. So don't justify the next wrongdoing in issue handling with "in 15501 it was OK" ;-) SBA->BH: technically, this is an enhancement. Sounds strange at first glace, but Oliver Specht told me about the two main problems in this case: 1. Replacing the whole selction At times, the F&R (Find and replace) dialog is non-modal (Resulting in independency from editing in the document. The dialog may stay open "all the time" to be "re-used" again and again). Note: A modal dialog (like "File-Save") would block all other operations within the document. Therefore the F&R dialog does not "know" if the current selection in the document was made by the user or by a former action of itself. That's the reason why "Replace" replaces the whole selection with the "Replace string". But this is normally not wanted, because for the replacement of a selection, one only has to start typing (the replace string) and not use the F&R dialog => FEELS like a bug! 2. In Writer, only one "kind" of selection is possible. Therefore "finding and selecting the search string" makes a new selection (be it one string or "multiple") and the old selection is LOST, thus no further hit of the next occurences within the "former" selection. SBA->BH: In total, this is an area where two things need to be changed in order to fix this unexpected (and unwanted) behavior. Maybe the F&R dialog can get smarter in order to "get" who made the last selection, but I can't tell. In my opinion even Prio2 is justified because the replacement of the selection when pressing <Replace> bears the risk of data loss (unwanted deletion of text). The "simple" solution of disabeling the "replace" button until to "protect" the text is not possible, because - as said above - at times this modeless dialog does not know where a selction comes from. I do vote for this but it is an enhancement that needs to be implemented to fix the big problem the current UI brings. From the user's point of view, this is a clear bug. Removing the "selection" option entirely would surely result in an outcry because there are indeed many cases where "Find all in selection" is a good thing. And simply finding something in a selection works. Note: MS Word does not offer a limitation to a selection at all, so OO.org is somewhat ahead already ;-)
Hello Oliver, do you have any idea for a solution fitting for the 'Q'? Please give approval for this evaluated OO.o 2.0 flagged issue. If you confirm with the target OO.o 2.0, then please keep it on your owner (or the owner of the concerning developer) for implementation. In case you want this issue for 'OOo Later', then please reset the target milestone. If you decline the issue finally, please set the resolution to 'Wontfix' (but do not close). In case of 'OOo Later' or 'Wontfix' please reset it on Bettina's owner. Thank you.
This will not be solved for OOo 2.0 -> Target changed and reassigned.
*** Issue 26861 has been marked as a duplicate of this issue. ***
SBA: Adjusted summary to reflect the findings.
problem with 'replace' replacing whole selection is also mentioned in issue 49456. i just stumbled upon both these problems and they are pretty nasty. it seems that there is no way to make multiple replacements on a single selection (maybe some macro that would record selection, replace, then restore it - though that would be pretty hard to implement to work with replacements that modify paragraph breaks and/or selections that don't contain whole paragraphs). will both these issues be handled here ?
I checked with "2.0.2 German version WIN XP: [680m5(Build9011)]" and also (still) saw the problem
sba Mon Jun 16 15:19:02 +0000 2003 wrote:"2. In Writer, ... "finding and selecting the search string" makes a new selection (be it one string or "multiple") and the old selection is LOST, thus no further hit of the next occurences within the "former" selection." Possible solution: Writer puts a 'marker'(some invisible char or string) at the end of the selection when the search begins) then (never mind the 'lost' selection) searches and replaces up to that marker (which, depending on the replacement string) could 'move' away or closer. The 'path' to the marker must also be defined, eg, when a table column is selected: the search should not stray outside the column.
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".