Issue 15501 - Search and Replace "within selection" loses selection after one operation
Summary: Search and Replace "within selection" loses selection after one operation
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1 Beta2
Hardware: PC Windows, all
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: oooqa
: 26861 (view as issue list)
Depends on:
Blocks:
 
Reported: 2003-06-11 11:09 UTC by Rainer Bielefeld
Modified: 2013-08-07 14:38 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Testfile (8.59 KB, application/octet-stream)
2003-06-11 11:12 UTC, Rainer Bielefeld
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2003-06-11 11:09:54 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
Comment 1 Rainer Bielefeld 2003-06-11 11:12:49 UTC
Created attachment 6795 [details]
Testfile
Comment 2 h.ilter 2003-06-11 13:56:13 UTC
Reassigned to SBA
Comment 3 Unknown 2003-06-12 11:34:23 UTC
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"
Comment 4 number5 2003-06-12 12:07:06 UTC
Confirmed (OOo 1.0.3.1, german / Win2K)
Comment 5 number5 2003-06-12 12:10:11 UTC
Confirmed (OOo 1.1 german / Win2K)
Comment 6 Rainer Bielefeld 2003-06-12 12:21:46 UTC
I think this is proved for WIN.

Can anyone test with other OS?

Rainer
Comment 7 Unknown 2003-06-12 22:13:03 UTC
Confirmed (OOo 1.1Beta2 German / Linux)

Also the additional bug concerning "Replace" can be confirmed.
"Replace all" seems to work.
Comment 8 stefan.baltzer 2003-06-16 16:19:02 UTC
-> 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 ;-)
Comment 9 bettina.haberer 2003-10-20 16:18:50 UTC
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.


Comment 10 Oliver Specht 2003-10-22 07:11:22 UTC
This will not be solved for OOo 2.0 -> Target changed and reassigned.
Comment 11 stefan.baltzer 2005-06-17 13:54:46 UTC
*** Issue 26861 has been marked as a duplicate of this issue. ***
Comment 12 stefan.baltzer 2005-06-17 13:58:54 UTC
SBA: Adjusted summary to reflect the findings.
Comment 13 richlv 2005-07-05 13:45:41 UTC
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 ?
Comment 14 Rainer Bielefeld 2007-01-14 17:47:56 UTC
I checked with "2.0.2  German version WIN XP: [680m5(Build9011)]" and also
(still) saw the problem
Comment 15 tab 2009-05-07 02:28:43 UTC
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.
Comment 16 bettina.haberer 2010-05-21 15:15:01 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements".