The official source of product insight from the Visual Studio Engineering Team
In Visual Studio 11 Developer Preview we’ve streamlined and modernized our vast array of Find experiences. Find and Replace is now a lightweight control within documents, delivering incremental search results as you type. The Find and Replace in Files dialog has been simplified while at the same time gaining additional functionality such as Find Next and Find Previous. Both Find experiences now let you use .NET Regular Expressions to perform complex search and replace operations, even across multiple lines.
The new Find control sits at the top of the document as a search box. Ctrl + F now brings up this control, instead of the dialog. The new control affords all the capabilities of the dialog. You can Find Next, Find Previous, set Search Options, Replace etc.
With the new Find control, you can perform a search exactly as you would with the VS 2010. Just hit Ctrl+F and type the search term. What you would notice however, is that now the search is instant and incremental. As you type, you get the matches highlighted and the first match selected by default. No need to click an additional Find Next button. Hit Enter to navigate among the matches in the document.
As I mentioned earlier, the new Find control affords all the capabilities of the Find Dialog. This means that you can search using advanced options (Match Case, Match whole word, Use Regular Expression) just the same as in the Find dialog. For this, simply click on the drop down next to the magnifying glass, in the search box. You can also hit Alt+Down when inside the search box.
Notice that setting Search Options acts like a filter instead of starting a new search. So if you searched for “Button”, without Match case, this would highlight all matches – button as well as Button. Checking Match case would filter this result set to only matches for Button (with the uppercase “B”)
Find control maintains a history of the previously performed searches of up to five terms. This is displayed as a MRU (Most Recently Used) list. The list can be accessed by bringing up the dropdown from within the Find search box (or hitting the Alt+Down arrow key)
You can perform a Replace operation right within the new control. Just hit Ctrl+H / click on the drop down arrow to the left of the search box. This brings up the expanded version of the Find & Replace control. The replace box is below the Find box. Type your replace term and Hit Enter, or Atl+R or the Replace Next or Replace All buttons.
Replace Next and Replace All
The Find control allows you to change the scope for Find & Replace operations. To change the scope, click on the Drop down arrow, as in the case of Replace. This brings up the expanded Find control with the scope selection dropdown.
The Find control allows you to quickly find out when there are no results for the current search term with the current search criteria. When there are no results to show, the search box is highlighted with a red border indicating that there are currently no results to display.
One of the major changes we have made, in response to customer feedback, with the new Find experience is moving away from the POSIX style regex syntax to .Net Regex syntax. You can do all your searches using the familiar .Net style regular expressions. The VS2010 style regular expression syntax has been discontinued. So, to search for a “Start Game”, I would type
In Visual Studio 11 Developer Preview: Start\s+Game
In VS 2010 (This will not work in VS 11 Developer Preview): Start:b+Game
A complete reference for .NET Regular expressions can be found here .NET Regular Expression Cheat Sheet.
You can still do everything that you were used to doing with VS2010 Find Dialog with the new experience. To bring up the Find In Files dialog, simply hit Ctrl+Shift+F (or Ctrl+Shift+H for replace). This brings up the familiar dialog. We have simplified this dialog to a large extent. There are just 2 tabs – Find In Files and Replace In Files.
Find In Files
Now there are only two tabs – Find In Files and Replace in Files. We have added Find Next and Find Previous. Note that you can also bring up the Find In files dialog from within the Find control, in the Search Options dropdown.
With the new Find experience we have relooked at the Find dialog and redesigned it for simplicity. Based on the usage data we have received from our Customer Experience Improvement program, the Find Symbol features was rarely ever used by our customers. With the new Find, the support for Find Symbol has been removed from the UI. However, you can still search for symbols using the Find All References from within the Editor.
You can of course use the same short-cuts and accelerator keys that you are used to with the Find dialog, with the Find control. Here is a list of shortcuts and accelerator keys you can use to work with Find & Replace in Visual Studio 11 Developer Preview.
VS 11 Developer Preview Action
New Quick Find
Find Next Selected term
Find Previous Selected term
New Quick Find / Forward incremental search
New Quick Find / Reverse incremental search
Find in Files
Replace in Files
Find Next, Find All (buttons)
Replace, Find Next
Replace All (button)
Skip File (button
Toggle Match Case
Toggle Whole Word
Toggle Regular Expressions
Focus in Find What Box
Focus in Replace With Box
Because Find is such a critical and integral part of the Developer experience, we need your feedback on how well the new experiences are (or are not!) working for you. We are listening to your feedback.
If you have any additional questions, feel free to leave comments below. If you’re experience problems with Find & Replace, please file a Connect Bug, and we’ll investigate
You can write to us here: VSFindFeedback2@microsoft.com
You can also send your feedback from within the Find control:
Thanks,Murali Krishna Hosabettu KamaleshaProgram Manager - Visual Studio Code Experience
As you might imagine, with the new release, we have completely revamped the Find experience for our customers. With this huge change, there are some known issues and unfortunately we didn’t have time to fix by the time of this release of Visual Studio 11 Developer Preview. However, these issues are already fixed in internal builds and you would be able to get these when you install a subsequent release J.
In the current version, you will not be able to perform a Find All when the scope is current document. However, when you search for a term using the new Find Control, all of the matches in the current document are highlighted. This should hopefully allow you to work around this issue. And like I mentioned, this issue has been fixed for a subsequent release.
In the current version, when you perform a Find in Files, the results are appended to the Find Results window. The results of the previous search are not cleared. To work around this issue, you can still clear out the Find Results window manually. We understand this is inconvenient and this has been fixed, but you will have to wait for a subsequent release. J
When you perform a Find All operation, the search results are populated in the Find results window. In the current version, the results are still populated, but a line mentioning the search criteria is missing. For subsequent releases, this issue is also fixed.
"I wasn't necessarily trying to convince you, I was trying to simply respond to your complaints with an alternative perspective. If you aren't interested in that then I apologize."
What is the alternative perspective? I am honestly trying to find out. I ask for the third time, why did you rewrite the feature? This is a simple question. You said there was a lot of negative feedback on the old dialog:
"There has been a lot of feedback from a lot of people that it *wasn't* working all right."
Yet the new, reworked Find & Replace system seems to behave almost completely like the old system (you added the highlighting but lost Find Symbol). What was the feedback? What did you improve? Please be exact. I know that different people can have different perspectives. I am asking a simple thing: what was your perspective when you decided to rewrite the feature? I simply don't understand why you thought it was a good idea to rebuild what is essentially the same functionality.
Sorry, it seems I've caused confusion by using incorrect technical terms. What I meant actually there two types of search box AFAIK: 1) with a modal/modeless window, and 2) inlined. In modal/modeless window, it still uses a separate container: window. While in inlined, there's no such window and instead it blends into the parent container: the text editor. So, it's all about *inlined* search experience, without window or similar container.
As I said, I think you could use the analogy of inlined search in a browser like IE/Firefox/Chrome. And notice how it has given a better user experience to the users.
> If you don't want it to obscure text, you can move it to a second monitor (if you have one) or dock it as a pane. If you work with at least one pane opened (say, Solution Explorer), docking the dialog as a pane works pretty much like the new system in that the dialog is out of the way and lets you focus on the text editor yet you can get to it by pressing a shortcut key.
That's what I've said previously, I don't actually like moving the modeless search window when it obstructs the text behind. Moving thing unnecessarily took my effort, and I don't want to do that *repeatedly* as I often use the search box. By making it inlined, it becomes effortless for me. Also docking is very limited in VS. You *can't* dock it at a specific location inside the text editor. I don't know exactly what the correct term is, but perhaps it sorts of subdocking/multi-level docking.
OK, aside from this whole endless conversation about this feature. It seems your frustation comes from the fact that MS wasting effort on this new feature (which useless according to your opinion) and not fixing important bugs you want. So, have you actually told them which specific bugs you'd like to be fixed? And how does that satisfy you?
ok, I really don't want to get into this little argument, but @Ryan, your argument is intellectually dishonest.
> >Brilliant. With this, if you don't like the results of your poll, you can freely ignore it. Way to go.
>No, I was simply pointing out that saying that something is at the top of the site == it is automatically slated for the next release is not accurate
No, that's not what you were pointing out. What you were pointing out is this:
> >Given that there are plenty of other, much more important problems, eg, a dog slow IDE? I don't think so.
> Again, you seem to imagine that your ranking of what is important is universal.
You were implying that it is wrong to assume that there are "plenty of other, much more important problems, eg, a dog slow IDE", and that people who think performance is a bigger issue than search/replace are out of touch with your userbase as a whole.
PleaseFixYourBugs believes that to the users of VS, performance is seen as a bigger issue than search/replace. You strongly implied that this is incorrect, that it would be wrong to assume this prioritization to be universal.
Is that so? Do you have data indicating that more people care about search/replace? If so, you had no reason to suddenly pretend that you were talking about something entirely different. And if not, I think you owe @PleaseFixYourBugs an apology for trying to brush off his concern with an invalid argument, and then denying that you did so.
If your first statement was incorrect, admit it. Otherwise stick by it. Please don't just pretend that what you said was something entirely different. That's just insulting.
@Maximilian Haru Raditya:
I get what you are saying about the separate container, but I don't get why having the feature inline vs having it in a separate container is so important. Yes, some users might prefer the search controls be part of the window, but I can assure you that some prefer the search controls be in a separate window too. One reason would be that a separate window can more readily host controls customizing the search options. Another reason would be that a separate window is what the UI guidelines suggest you do, and is a standard interface, unlike the inline controls. I believe one could argue from both sides here and it is puzzling to me that the dev team would choose to spend their time switching from one side to the other "just because", without making any significant improvements to the feature.
The example with IE doesn't count since the Find dialog in IE was truly modal.
"It seems your frustation comes from the fact that MS wasting effort on this new feature (which useless according to your opinion) and not fixing important bugs you want. So, have you actually told them which specific bugs you'd like to be fixed? And how does that satisfy you?"
Yes, I, my team, as well as many other people did told the dev team about the specific problems we are having. We did this via the Connect site (lots of bug reports), via email, via blogs, via polls, etc, etc, for years. Most of the time the response from Microsoft (when they grace us with such, you don't always get lucky to have a non-automated reply) is that they acknowledge a problem, but they aren't going to fix it because they don't have time, because there is a workaround (even if it is ugly, time consuming and doesn't always work), because the problem doesn't meet a certain internal criteria they currently use to triage, etc. This is going on for years.
To witness this first hand, please take a look at the Connect site and count how many bugs for VS are reported only to be closed as "won't fix". Even simpler, take a look at this very thread. Ryan Molden from Microsoft is already talking cautiously that the results of the polling on the Microsoft's user voice site, which show unequivocally that the number 1 problem with Visual Studio is performance, might not matter much in reality due to the selection bias. Sigh...
So, yes, I have actually told Microsoft about the bugs and problems I am having, numerous times, and the reaction from Microsoft does not satisfy me at all.
I have been asked by the team that owns this feature to stop responding to this thread as I am not a spokesman for the team or for Microsoft, so I will honor that request.
This is my last response and it is intended only to make explicitly clear that my original involvement was in no way meant to 'dismiss peoples concerns' or be 'intellectually dishonest' or to claim that a revamped search experience was 'more important than perf'. If it came across that way I apologize, it was not intended as such and was likely due to poor communication on my part. I was only trying to have a conversation about the topic at hand, but it seems I have succeeded only in muddying the waters and upsetting/misleading/insulting people which was never my intention.
In the future I will leave communication up to the PMs and teams that own the features to avoid this kind of situation.
I think I like the inline search pane slightly more than the dialog, but I have to agree that this is a very small and, ultimately, unimportant thing.
Also, +1 to grumpy.
Thing is, this is totally useless. With the old dialog, you had several keyboard shortcuts to _quickly_ change the current serach's behavior.
Now you hide everything in dropdowns and floating menus whihc require you to find your mouse, navigate to the upper right corner and start clicking.
A simple "type in your text, alt+c, alt+w" (make the current search case sensitive, whole word) turns into a clickfest. (and don't get me started on quickly changing the scope from single file tosearch in project/solution/dir etc)
With the vs2010 addin at least i have the option to disable this stupid window, but i cannot seem to find the old behavior in vs2011.
Apparently you didn't read the blog post, where it specifically calls out of the shortcuts/accelerators (including Alt+C and Alt+W) that work with this new tool.
Firstly, I would like to thank you for your feedback! I am the PM on the Visual Studio Editor team. I see that there are a couple of points here and I would like to clarify.
1. Why update Find ?
Find represents one of the top 50 most frequently used commands used in Visual Studio. Over the past one year, we have monitored multiple feedback channels closely such as Microsoft Connect to identify the top customer pain points with Find.
The top three areas where we have improved the experience for our customers with the new Find:
• Incremental Search
This feature allows you to quickly perform a search and navigate instantly to the first match in the current document – just hit Ctrl+I and type your search term; it immediately navigates to the first match in the current document, incrementally as you type.
Users of incremental search love the feature and use it heavily. But most users didn’t know about this feature. ISearch was not discoverable. With the new Find Control you get this incremental search experience by default. Hit Ctrl+F and type the search term – it immediately navigates to the first match, but also highlights all the matches in the document for that search term. All of this happens incrementally giving instant results.
• Find gets in my way
The Find dialog covers too much code. The dialog tries to get out of the way, but users would have to chase it around in the IDE.
The new Find control takes up nearly 8% of the space of the dialog. It remains stationery in a consistent location at the top of the document.
• Which Find do I use ?
In Visual Studio 2010, the Find dialog had too many options – there were too many tabs and too much duplication. The Find Dialog had four different tabs – Quick Find, FindInFiles, QuickReplace, ReplaceInFiles providing the same functionality. Each tab allowed you to perform a search/ replace in all the scopes – Document, Project, Solution, Open Documents etc. Which Find do I use when ?
We have unified the multiple tabs in the Find dialog into two tabs with all the functionality. You get one tab for find and the other for replace. You will be able to perform FindNext, FindPrevious, FindAll and BookmarkAll from within a single tab. We have also optimized the scenarios where Quick Find is used vs. where the Find dialog is used. Ctrl+F gets you to the Find Control which provides quick find optimized for the current document. If you want to search beyond the scope of the current document, you use FindInFiles (Ctrl+Shift+F).
2. .NET alternative to the :i pattern
There is an MSDN article on converting the Visual Studio regular expression syntax to the .NET syntax. Please refer to Using Regular Expressions in Visual Studio
With the .NET regex syntax, you could use this expression for matching identifiers. \b(_\w+|[\w-[0-9_]]\w*)\b
3. Alt+F12 – does it work ?
This time around, we took a hard look at simplifying the Find experience. When we looked at the usage data for FindSymbol, we figured that either our customers are not using this or the feature was not discoverable. Furthermore, FindSymbol functionality is provided by the Solution Explorer as well. You can search for symbols through the Solution Explorer. The new Solution Explorer provides a Search feature which allows you to search through the symbol table. We would be glad if you could try out this feature and let us know how it works out. Ctrl+; is the shortcut to search in the Solution Explorer.
While we can't comment on what features are in the final versions of Express at this point in time, we can confirm that the improved Solution Explorer support is present in the Visual Studio 11 Developer Preview
Alt + F12 is not supported.
P.S: Some emails to the feedback link VSFindFeedback2@microsoft.com were not getting delivered earlier. This issue has been resolved now. Your feedback is valuable. Please feel free to write to us.
Thanks again for your feedback! If you think of anything else while using Find please do let us know.
Hey great! I have *always* hated the find/replace mechanism in VS since as long as I can remember. It was probably VC6 when I last didn't hate it.
I haven't used the process described above so I can't be certain of this, but from what I read, I am super happy that you guys have worked on it. On that basis I like the look of the solution so far.
It's a small feature, but I use it all the time so it could be a big impact to fix it - for me at least - for relatively small effort. I'm glad your data appears to back that. This kind of quick tactical win I am all for. I agree with @PleaseFixYour Bugs big picture wise but I accept your arguments on this and also for the reasons I just gave.
@PleaseYourBugs As far as I know, the poster was likely right that the find/replace guys wouldn't have worked on performance etc. had they not been working on this; because as far as I understand, MS has feature crews for each of those area.
But regardless, it seems natural that peformance issues might be looked at by either dedicated performance experts and/or the original authors/crews of a particular component that was found to be slow. So in that context, and there is some common sense to it, it seems quite reasonable that the people working at the find/replace dialog UI level would not be core to either of those crews. The skills aren't an obvious overlap anyway, though of course it's possible.
PleaseFixYourBugs, we want many of the same things but I think ryan et al weren't saying anything outrageously wrong here, even if you didn't agree with them. When answers are within the bounds of reasonable, IMHO a softer style would have been fairer here. I'm all for "say it like you see it" or if you like, harsh but fair where appropriate - see my C++11 priority posts expounding what appear to be similar views to yours for example - but guns blazing 24x7 is a lot of bullets and this isn't picking your battles and doesn't help win support for your cases, which mostly I do support. :)
@Glen: You are right. Point taken.
@Murali Krishna Hosabettu Kamalesha: Thanks for the reply. I apologize for perhaps being a bit too bitter and I appreciate your willingness to talk despite of this. I am still disappointed that you have chosen to work on Find & Replace rather than on something more significant, since the benefits are, in my view, very minor (what you said above proves that I haven't missed anything about the feature earlier and, well, I said enough about the lack of real benefits already, everything I said stands). I wish you were spending the majority of your time working on features like those upvoted on the user voice site. Judging from the preview version of vNext, you didn't have much chance to improve those areas yet. I hope this will change in the real release. Good luck.
MSFT guys, please please don't limit remebered searches to 5, up to now 20 were remebered, it's important for big projects (I search through 2 million lines!)
Simlpe Escape key in Output or Find results windows closed them in VS6, any chance to allow that in the next version? Now I don't know how to close them from keyboard to free the vertical space for the code!
Sorry if this was already called out elsewhere and I missed it, but is find+replace async WRT the UI thread? When I do large find/replace operations (especially with regex) currently, VS is effectively 'dead' for a long time (at the moment, it's been 8 minutes for the one that's currently running). It's not pumping messages much, if any (Resource Monitor lists it as 'Not Responding', the window chrome occasionally shows up and then disappears again, etc).
I'm fine if the cpu and disk make the rest of my VS experience slow, but it'd be nice to have such operations (running way over 50ms! :) not to lock the whole IDE. :)
I have a similar idea for VS: visualstudio.uservoice.com/.../2255881-adopt-metro-ui-design-philosophy-fast-and-fluid