Bug 5305 - Find Next does not work after switching to a different window
Summary: Find Next does not work after switching to a different window
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: 3.0.x
Hardware: Macintosh Mac OS
: Normal enhancement
Target Milestone: 4.2.4 (from master)
Assignee: Mike Krüger
Depends on:
Reported: 2012-05-24 11:43 UTC by chris
Modified: 2014-02-13 08:35 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description chris 2012-05-24 11:43:34 UTC
After doing a "Find" or "Find Next Selection" I want to be able to switch to a  different window and continue with "Find Next" (same behavior as VS).

Currently this is not possible because the new window 'forgets' the current search term.

- open any .cs
- use "Find" to search for "class"
- switch to another .cs
- use "Find Next"

- it doesn't find anything

- it should find "class"
Comment 1 Mike Krüger 2012-05-25 01:34:22 UTC
Each buffer has it's now search string atm.
Comment 2 chris 2012-05-25 02:22:33 UTC
So this is by design?

I'm not sure why anybody would want this behavior but can you please add an option to make it work like Visual Studio?

This has bugged me a long time (I use "Find Next Selection" a lot) and I never understood why it wouldn't remember my search from one window to the next.
Comment 3 Mike Krüger 2012-05-25 07:47:21 UTC
Atm it's by design - but not by intention, I used some editors where it was like that.

(gedit for example does it too)
Comment 4 Mikayla Hutchinson [MSFT] 2012-05-25 11:50:52 UTC
I can't see any way to make this work well with the per-document incremental search entry. How does VS11 handle it?
Comment 5 chris 2012-05-25 14:49:29 UTC
In VS it doesn't matter if you search with Ctrl+F (dialog) or Ctrl+I (incremental) - after I search in one document I can switch to a another one and continue to search (using the last search term) with F3.
Comment 6 Mikayla Hutchinson [MSFT] 2012-05-25 15:44:43 UTC

I specifically said VS11 because they changed the search experience and it's much closer to what MD does.
Comment 7 chris 2012-05-25 15:58:17 UTC
The only thing different in VS11 is that both Ctrl+F and Ctrl+I take you to incremental search. Otherwise the behavior is like I described it (you can continue to search with F3 in another document window).
Comment 8 chris 2013-01-03 09:50:56 UTC
Are there any plans to implement this feature? thanks.
Comment 9 Mike Krüger 2013-01-04 02:43:52 UTC
I think we'll implement that after the next major release. We hadn't really the time to work on the search features for that and are in a feature stop phase.
Comment 10 chris 2013-03-17 16:34:28 UTC
Now that Xamarin Studio has been released, would it be possible to implement this feature? It would really help a lot!
Comment 11 Mike Krüger 2013-03-18 01:34:08 UTC
It's already implemented - just didn't close this issue.

(If it's not in 4.0 - 4.0.2 will have it)
Comment 12 chris 2013-03-18 03:15:03 UTC
I didn't find any options but do I need to configure anything? 

I just switched to the Beta (4.0.2 Build 18) and it still has the old behavior.
Comment 13 Mike Krüger 2013-03-18 03:17:09 UTC
No should just work
Comment 14 Mike Krüger 2013-03-18 03:24:21 UTC
Ok was a bug in find next.

I've a slightly different search behavior:

Switch files then hit find -> pattern is memorized (it's even possible to use the 'find' as 'find next' - but has a slightly different behavior).
Comment 15 chris 2013-03-18 07:34:27 UTC
I've tried but the pattern is only 'memorized' for the first search.

- search for x in file a
- open search in b (shows x)
- search for y in b
- open search in a (still shows x instead of y)

I've reopend the bug if that's ok.
Comment 16 Mike Krüger 2013-03-18 08:00:19 UTC
y, np - it's part of the same issue somehow.

Comment 17 Nischal 2013-03-19 07:58:28 UTC
Today, we have verified this issue with the latest builds:

MFA 4.6.01072
Mono 2.10.12

And now this issue is not appearing, as user is successfully able to find next even after switching files, moreover search box of both the files function as per the text in their respective boxes.

Hence, closing this issue.
Comment 18 chris 2013-04-02 11:54:08 UTC
I've switched to the latest beta Version 4.0.3 (build 13) but the issue is not fixed there (it behaves like described in issue 15).

Shouldn't it work in the beta as you verified it as fixed in XS
Comment 19 PJ 2013-04-02 12:03:35 UTC
It looks like they verified the initially reported behavior, but not the behavior in comment 15.

Mike, did the fix from comment 16 make it into the release branch? 

Nischal it looks like your missing step is the *second* search. The issue it seems is that the behavior is correct on the first search and file switch, but then if you search again and switch back, the search on the first page isn't updated.
Comment 20 Mike Krüger 2013-04-03 01:14:17 UTC
No I don't think that it's in the 4.0.3 branch - but it's working in master I just checked it again.

@chris: our release & branching strategy is a bit conservative expect that the next release lags roughly 1 month behind :/

Comment 22 chris 2013-04-03 02:28:37 UTC
@Mike Krüger great idea! :)

Could you also list which bug #'s were fixed in your release notes?
Comment 23 chris 2013-10-05 18:21:14 UTC
Sorry to report that this bug is back in 4.1.12.
Comment 24 Mike Krüger 2014-02-12 03:11:33 UTC
Should work in 4.2.4