No, just anything that would normally “dirty” the document, would also disable the replace/all buttons. Search would enable them.
Not an optimal solution, but far simpler than trying to implement search hit tracking etc. as Norman pointed out previously.
It could function on the same idea you have.
If the user dirtied the document, search again before replacing.
It should be automated, behind the scenes, and not inhibit the user (BECAUSE I’M SPECIAL)
I’m just thinking, what happens when 1 result is selected and the document is changed? Perform the search again and try to find the same result to select before -hopefully- replacing the correct result? Sounds bad to me.
I’m thinking more along the lines of just preventing disaster. You really shouldn’t mess with a project in the middle of a search and replace, but if you did there’d be no replace available until you refresh the search.
We’re still back to tracking WHEN the search was done relative to the last change to any item in the search results
Which we dont do
No need to track anything. It would be a flag that is set when a search is performed. Unset when the doc changes.
The changes vs results is irrelevant since the behavior is project wide. Any change affects (seemingly) any replace anywhere.
Right - we have no such flag
Adding one and making sure it gets set / reset etc at the right time now is the trick
I’ll quote myself from earlier in the thread since its relevant
Doesn’t mean “and we never will”
Just we dont right now[/quote]
How about simply doing the search again before replacing?
Would it not be possible to solve this by checking the data that is going to be replaced with the original search terms to confirm that it still matches?
That would work for “Replace All”, but what about a limited replace? You can’t reuse the existing dirty project flag or you’d have to save before every search.
There is no way this is a trivial fix. I’m just glad that every time I’ve searched to replace it has worked because I don’t change the code between steps.
Anyone who has fixed reported issues from a build that required adding a line will have experienced a similar issue - the error pane no longer shows the correct lines of code. I accept that I’ve change the playing field and work with it.
I’m sure however that @Norman Palardy will work with scenario’s and come up with the best option.