Dick, thank you for taking the time to share with us your suggestion.

Duplicated on Win NT 4.0 SP6a, OOo 643.

After running Find & Replace, cursor should return to the original 
position before the search started.

User summary
Cursor is left in final position after Replace All

JA->FT: reassiged as RFE to you

Find (& REplace) is a text edit function. Onvce you edit the text you
place a cursor.
Hence this is your new edit selection (abandoning the old). Your
request would change this standard behaviour for a single case.
This is not accepptable and would lead to confusion with most user
(jumping cursors are not what one wants).

closed

SBA: Reopened. 

I think that what FT wrote is the TECHNICAL justification of what happens at
times (Same in OOo 2.04, by the way). See issue 69402 for further information
(closing issue 69402 as duplicate).

The users expectation CAN indeed be different. MS Word does not leave the
current view area.
The case "I rework a huge document, I want to go through it step-by-step and
when I find something, I want to "change all" and continue to where I was
before" is very close to real life.

If the cas is "I want to see where the last change is made", then a repetitive
"Change" will "guide to the document until the last occurrence", if that is
wanted. Or go to the end of the doc, search backwards, then change all and stay
at the last occurrence (i.e. if it is too many occurrences)

Yet-another-option is surely not what we want. Users are already overwhelmed
with them.
This is a case where I do support "Yet-another-Standard-introduced-by-MSOffice".

*** Issue 69402 has been marked as a duplicate of this issue. ***

SBA: Reassigned to requirements.

*** Issue 55452 has been marked as a duplicate of this issue. ***

*** Issue 75415 has been marked as a duplicate of this issue. ***

Dear developers,
please consider this feature for some not too-distant release, for example 2.3 
or 2.4.
Thanks a lot.

The problem with this issue is that it's easy to rush things here. 

I understand that users might get back after searching. Here we find only the
"replace all" case but why should we stop there? Wouldn't it be useful to have
the same functionality for "replace" or "find"?

But how should several consecutive search/replace calls be handled? Should we go
back one step only? Or should we go back immediately to the start?

There's also another, comparable case: a user has clicked on a reference/link
and now wants to go back to the place where the link is (issue 5608). Should we
mix this "history" of clicks with the "history" of search results? Keeping both
separated would create bloat IMHO but mixing them OTOH could be confusing. 

And at what time should we throw away the "history"? Should we throw it away as
soon as the user navigates or changes the selection? Or only when the document
is modified? Choosing the first option could solve the problem of having two
histories as clicking on a hyperlink then will automatically clear the history
built by searching and vice versa.

And do people expect also to be able to jump in both directions, back and forth,
pretty much as they can in a browser?

The next interesting question is the user interface. Surely we need a shortcut.
Should we have a button also? IMHO the toolbars are overcrowded already. But
perhaps an optional one makes sense.

The implementation of the basic feature can be comarably simple: I would just
store the current selection on a stack and restore it on demand.

I'm sure we find some more interesting questions. :-)

*** Issue 86707 has been marked as a duplicate of this issue. ***

All the technical explanations are not of real interest for me. As a translater 
and revisor I am nearly every day in the situation that I have to replace an 
expression throughout the whole document when I see it for the first time. 
Because I have to go revising on that very same place, it's just copious to 
have to refind that place by searching for it, or placing a marker or making 
another detour.

I just want to have a "go-back-to-start-of-search/replace-all" button! And I do 
NOT say "because Word has it", I say because it is an important and necessary 
tool for people who work with texts seriously!

Amen to that. :)

I've been using Openoffice on and off for many years and I think I am the one
who pointed out this amateurish behaviour of the program some six (!!!) years
ago. What does it take to persuade a programmer that a blunder has to be
corrected? Sorry for the sharp language, but only today I had to go fumbling
back to the part of my 450-page text I was editing at least ten times. I am
really disappointed and frustrated and of course it is a shame for the
Openoffice programming community that a small detail like this is still being
dragged along from question to vote and from vote to question after six whole years!

wolle2000, lkaratzas,
the problem at the moment is _how_ you want the feature to behave.

Do you just want to save position when Search&Replace dialog is called and 
restore the position when dialog is finally closed?

Or you would like to use the opportunity and introduce some handy 
sophistication in behavior?

@ kpalagin,

I don't know what you mean by "handy sophistication", but as I already said I 
would be happy with an additional button (for example "Back") which brings me 
back to the point where I was when pressing "Replace all".
Not more and not less. 

@lkaratzas 
You have my deepest commiseration and sympathy!

Wolfgang

Actually, I really looking forward to see this simple feature implemented, it is
very difficult to work with large amounts of text and look the starting point
after replacing all. 

2 kpalagin

Regarding your question, how we would like to see this implemented. 

I am working with big texts and I make global replace several times without
closing Search&Replace window (it just sits on the right), so it would be really
great that position will be constant all the time. 

For example, if I made one global replacement, and I see I can make another one
in a sentence below, then I need to stay at the same position without closing
Search&Replace window. So I could just mark next word for a replacement and
copy&paste it straight into Search and Replace window.

Hope I was clear. Looking forward!

@mba: [q]I understand that users might get back after searching. Here we find
only the
"replace all" case but why should we stop there? Wouldn't it be useful to have
the same functionality for "replace" or "find"?[/q]

No. You can assume that if a user clicks Find, he/she wants the cursor to move
to the found text, if any. In the case of a single replace, maybe too.[/q]

[q]But how should several consecutive search/replace calls be handled? Should we go
back one step only? Or should we go back immediately to the start?[/q]

When a user clicks Replace all, the program executes the Replace all in the
background, so the changes aren't shown as the replacing takes place - that will
make the replacing a lot faster too and the cursor location won't change either.
If you need a cursor to perform each replace, then use a dummy cursor. You
should only redraw the text area when it gets focus again (sorry for the Delphi
jargon). ;) Hope this helps.

If we agreed to just keep the cursor where it is in case of "ReplaceAll" I agree
that it wouldn't be so hard to do. I've got a different impression from reading
sba's comment but obviously I was seeing things. :-)

We should evaluate the effort and further discuss that in our upcoming project
status review. Until then I set the target to 3.x.

I suggest that you actually use Writer to edit a fairly large document. That
will make clear to you why this is brought up by rather a lot of people. Let's
be pragmatic. OOo isn't a work of art ion display in a museum with art critics
commenting on the wonderful programmer's logic. It's supposed to be a
productivity tool, and the present behaviour is counter-productive. An option to
be taken back to where the cursor was is a big time saver.

I don't want an option here. We have plenty of them and plenty too much. I think
the RFE to not change the cursor position in "ReplaceAll" is reasonable and we
should just implement it. If you replace something in your document 47 times
none of the occurences is better than any other - so why jumping to the last
one? So I doubt that many users will miss the current behavior.

[q] When a user clicks Replace all, the program executes the Replace all in the
background, so the changes aren't shown as the replacing takes place - that will
make the replacing a lot faster too and the cursor location won't change either.
If you need a cursor to perform each replace, then use a dummy cursor. You
should only redraw the text area when it gets focus again (sorry for the Delphi
jargon). ;) Hope this helps. [/q]

That's exactly what I meant! It should really apply only for Replace All,
because it makes sense in this case.

@ mba,
Quote: If you replace something in your document 47 times
none of the occurences is better than any other - so why jumping to the last
one? So I doubt that many users will miss the current behavior. /Quote

Fantastic that this is seen after such a long time. I'm looking forward to 
version 3.0 :))

Wolfgang

There is a good reason for wanting to return to the last position before a
single Find or Replace: imagine you're happily typing away and suddenly you
remember something somewhere else in the document and you want to look it up or
fix it right away, and go on where you left afterwards. If you want to do that
easily now, you have to type for instance "qqq", do the Find, then Find "qqq" to
return. That's rather a lot of work. j/k
I can think of an easy way to add an option for returning the user to the last
cursor position after a Find/Replace (but not after Find all) as follows:

As soon as the Find/Replace is invoked by the user, save the cursor location.
Execute any commands by the user. When the dialog box is closed or the user
mouse-clicks in the text area, display a dialog box asking the user to be
returned to the last cursor location before the Find/Replace. You can skip that
dialog box after a Replace All.

Another idea (for use by hardcore people) would be the bookmarks introduced in,
IIRC, Wordstar, I've only seen it in Turbo Pascal 6, and I seldom used them, but
you could define up to something like ten bookmarks and then go to bookmark #n
by a simple keyboard shortcut, which I don't remember :).

Hope this helps.

Already in May 2007 mba wrote: "The implementation of the basic feature can be 
comarably simple: I would just store the current selection on a stack and 
restore it on demand."

Despite a lot of votes and passionate comments of users who urgently want this 
feature, nothing has happened. And what was Target milestone 2.x is now target 
milestone 3.x and - as I am afraid - will be target milestone 4.x in the end.

Here another quotation from the official announcement of OOo 3:
"OpenOffice.org 3.0 provides more flexibility and functionality than any other 
office suite on the market"
What a cheek is this, regarding the above! 

"Search and replace all" is not the same thing to most users as "replace and
search next until not found". This may be the implementation but it's not
expected. It should replace all occurrences as a single operation and not change
anything else. Changing the cursor position is a serious side effect and very
annoying. When searching and replacing interactively, I do expect the cursor to
jump because this is the implicit behavior of the "Replace" button in all apps I
know: "Replace and search next". Giving "Replace all" an implicit behavior of
"Replace and go to last replaced item" is unintuitive. I see the reason for this
behavior but not the purpose, the practical use of it, and that's what should
matter.

This bug has been open since 2002. For those who are tired of waiting for a fix,
the "Alternative Find and Replace" extension fixes it without even advertising
it: http://extensions.services.openoffice.org/project/AltSearch

*** Issue 107399 has been marked as a duplicate of this issue. ***

yes, this is the one thing I don't like about open office

I am a translator and having to scroll up and down every time I have finished a
find and replace (a lot!!!), is really very frustrating.

I hope they can fix this problem

Just revisited this issue to see if there'd been progress in seven years. The 
argument would appear to be won, the target set to 3.x. 
But I'm using 3.2.1 and no joy. 
I did check out the "Alternative Find and Replace" extension, and it does not fix 
the problem, neither by default nor akaics with an option.

again, now using 3.3 still no joy. Anyone here?

FWIW; I am not convinced we should change the current behavior but
just for reference the change can be made in
main/sw/source/ui/uiview/viewsrch.cxx

in the case SVX_SEARCHCMD_REPLACE_ALL

By using the SwCrsrShell stack before and after the search (line 306).
 
However, looking at how LibreOffice did it, it can be really somewhat
tricky: indeed it ended up causing regression after regression
(fdo#40831 fdo#49901).

Still not dealt with in 4.2.0 dev.

After so many years of waiting in vain, I've given up. The people with the most userfriendly office-suite of the planet are just too stubborn to fix one of the oldest and most pet peeve problems of this software. It's a shame!

As stated before: for "Replace All" it would be a good idea if the cursor doesn't leave its position. In all other cases I cannot see a benefit. But a little problem will be if the cursor stands inside a phrase that will be replaced. The "original" position exist not anymore after replacing.

As a hint for long texts: look at the navigator. There you find a paperclip icon "Set Reminder". Click it if the cursor is at the position that you want to reminder. You can reminder more than one position.

Open the mini navigator from the navigator (blue circle with white triangle: "Navigation") or between the navigation arrows at the lower right corner. Select the paperclip icon "Reminder" and switch with the navigation arrows at the right side of the mini navigator or now with the navigation arrows at the lower right side of the document window (they are now blue) between your reminders.

*** Issue 63200 has been marked as a duplicate of this issue. ***