ReSharper, day 8: Find Usages
Welcome to day 8 of my 31 Days of ReSharper.
As I mentioned in the survival guide, ReSharper replaces Visual Studio’s Find References (Shift+F12) with its own Find Usages (randomly changed to Alt+F7). Here’s more info on how their version differs from the one in Visual Studio.
Filtering for “get” or “set” usages
Ever had a property that’s read all over the place, but only set a few places, and you wanted to Find References to just the property setter? Here ya go.
This also applies to fields: you can find only places where a field is read, or only places where it’s written. (Man, if Reflector only had this feature!)
As you can see from the screenshot, the Filter menu in the Find Results window has options for “Show Read Usages”, “Show Write Usages”, “Show Invocation Usages”, “Show Other Usages” (I’m not sure what that means), and “Show Usages in Documentation” (I assume this means XML doc comments). I thought “Show Other Usages” would mean making a delegate that references a method, but apparently they use “Show Read Usages” for that.
They’ve said that in a future version, you’ll be able to right-click on the “get” or “set” keyword inside a property declaration, and select “Find Usages”, and get just the read or write usages, as appropriate. I’m looking forward to that one.
Stepping through the results
After you do a Find Usages, you can use Ctrl+Alt+Up and Ctrl+Alt+Down to step through the results. It’ll put the cursor on the next result, opening another file if necessary. It doesn’t wrap when you get to the end, which is nice in a way, because it tells you you’re done.
The Find Results tree
On the downside, I don’t really like the way they present the search results in the Find Results window.
In Visual Studio, everything was just shown in a list:
Every entry shows the filename and line number (and column number, as if you cared), so you at least know which class each reference is in. In ReSharper, on the other hand, everything’s in a tree:
The tree starts out collapsed every time, so you’re always at least one click (Expand All) away from even seeing your results. And if you change the “Group by” setting to “None”, in an attempt to get rid of those layers of tree and see your results right away, then you don’t get anything telling you which file a result came from: each line will show just the text of the matching line of code, but no filename or line number information.
(I sent in an enhancement request, asking for the ability to show the results expanded by default. They said that there were a lot of other people asking for the exact same thing, so we may see that happen at some point.)
On the other hand, once you do get them expanded, they can tell you not just which class the result was in, but also which method, something VS’s list doesn’t do.
February 8th, 2007 at 10:12 am
Reflector does this for quite a while. Expand the property in analyzer and it will show you the setter and getter method, expand it and you know where the property was set.
February 9th, 2007 at 12:36 am
Reflector works with compiled code, which is much easier, while R# even works with code that does not compile.
February 9th, 2007 at 9:54 pm
Post says: "(Man, if Reflector only had this feature!)". Point was Reflector does have this feature - there is no mention about context.
February 10th, 2007 at 8:55 am
Adrian, you’re right — I wrote the wrong thing. The thing I’m always wishing Reflector could do is to find just read accesses / just write accesses for *fields*, which is not at all what I originally wrote! R# can do this for fields; Reflector can’t. I updated the post to clarify. Thanks!
September 22nd, 2008 at 6:43 am
[…] I talked about one Visual Studio feature (Find All References) that ReSharper replaced, enhanced, and changed the keystroke for. Today I’ll talk about […]