CodeGear and roadmaps

We’ve been looking forward to Delphi Highlander — a Delphi for .NET 2.0 — since before it had a name. You can compile to .NET 2.0 with Delphi 2006 (and we do), but the IDE actively gets in your way, and you can’t use generics, which are the whole point of .NET 2.0 in the first place.

CodeGear’s “Borland [sic] Delphi Roadmapstill says that Highlander will [sic] be released in 2006. Way to keep your roadmap current, guys.

But the latest news is that the next release of Delphi will be strictly Win32. Apparently the next couple of releases won’t even have a .NET compiler.

And here I was hoping that they would actually ship what they’ve been promising us for over a year.

Silly me.

ReSharper, day 13: File Structure view

Welcome to day 13 of my 31 Days of ReSharper.

For several versions, Delphi has had a Structure view, which shows your fields and methods and properties in a treeview. ReSharper takes this several steps further with their File Structure view, which is accessible with Ctrl+F11. Not a great shortcut, but then, you’ll probably only show the window once and then keep it docked.

ReSharper's File Structure view

Sorting methods

Theoretically, you could use this to see your code’s structure at a glance. I don’t really use it for that; my fingers have the shortcut for Collapse All memorized (I think it’s Ctrl+M Ctrl+O, but I never have to think about it… let’s see… yeah, that’s right).

What I do use the File Structure view for is re-ordering. We find life is a lot easier if we keep all our methods alphabetical; but ReSharper doesn’t have an option for that, so it’s always putting extracted methods in the wrong place. But you can drag and drop in the File Structure window…

ReSharper's File Structure view

and when you drop the method in the new place, ReSharper will move the method in the Code Editor.

It sometimes does the wrong thing with respect to blank lines, but until ReSharper adds options to keep things in the right order (which, given the number of different coding styles out there, would be a tall order), drag-and-drop of tree nodes, followed by “collapse all” and a bit of blank-line cleanup, is a far sight faster than cut and paste.

If you like regions…

For those who actually use regions and like them, ReSharper’s File Structure view makes them all pretty and collapsible.

ReSharper's File Structure view, showing an expanded regionReSharper's File Structure view, showing a collapsed region

If you don’t like regions…

Personally, I think that regions make code harder to read — and besides, if your code is so complicated that you need regions to keep it organized, that’s a smell that your class is doing too much.

If you’re in this camp, ReSharper is there for you. See that little blue “X” in the top-right of the region box? A single click on that, and the region tags go away. (It only deletes the #region and #endregion lines, not the region’s contents.) And then, since you’re already in the File Structure window, you can go ahead and drag to reorder the methods.

Of course, if you accidentally remove region tags when you didn’t intend to, it’s a code change like any other, so you can undo it.

ReSharper, day 12: Type Hierarchy view

Welcome to day 12 of my 31 Days of ReSharper.

Today’s topic is a feature I’ve spent so long wishing for that I can never remember it actually exists: the Type Hierarchy view, accessed via Ctrl+Alt+H.

ReSharper's Type Hierarchy, showing the class hierarchy for System.Windows.Forms.Form

If you press Ctrl+Alt+H while the cursor is over a type name, it will pop up the Type Hierarchy window, showing the ancestors and immediate descendants of that type. (Like all the other ReSharper windows, it’s dockable.) You can expand the tree to show lower-level descendants as well. If you’ve got a complicated type hierarchy that you always access through an interface, you can see the whole tree just by cursoring to the interface and pressing Ctrl+Alt+H.

You can right-click on a node and select “Base on this”, which will re-do the tree as if you had pressed Ctrl+Alt+H on that type. If you do this on a class’s parent type, it will open up more classes in the tree (because you only see the based-on class’s direct ancestors; but if you base on one of those ancestors, you see all of its other descendants in the tree as well). The current based-on class is shown in bold.

ReSharper's Type Hierarchy, showing the class hierarchy for System.Windows.Forms.ContainerControl

I think it’s really cool that “Base on this” remembers which types you already had expanded and which were collapsed, and leaves them that way.

The Type Hierarchy window also has a couple of alternative views, accessible through the little object-graph-looking buttons on the right side of the toolbar. Besides the main hierarchy view, there’s a view that shows just the descendants, which isn’t that interesting; it’s just the main hierarchy view with less indentation.

The third view shows just the supertypes. The supertype view is interesting because it inverts the tree (parents are shown as sub-nodes), so it can show the interfaces a class implements, as well as its parent classes.

ReSharper's Type Hierarchy, showing the supertypes of System.Windows.Forms.Form

The right-click context menu, besides “Base on this”, has Find Usages and a Refactor submenu. So if you’re looking at a type hierarchy and feel a sudden need to rename one of the classes in it, you can. (It’s smart enough to gray out things like Rename for classes you don’t have the source code for.)

Finally, you can double-click a type in the tree to jump to it in code. (Although it uses the klunky Class Browser instead of Visual Studio’s new “[from metadata]” code view for types you don’t have the source code for.)

ReSharper, day 11: Code navigation

Welcome to day 11 of my 31 Days of ReSharper.

Today’s topic is navigation through the code. I’ll cover three ReSharper features: the Navigate From Here context menu; the gutter icons; and Go To Declaration.

Navigate From Here context menu

One of the cool things about ReSharper is that they have more than one context menu. They have a couple of keystrokes that bring up targeted context menus, so instead of “everything you might possibly want to do here”, you can see “everything you might want to do related to code navigation” or “everything you might want to do related to refactoring”. (The kitchen-sink context menu is, of course, still available.)

These targeted context menus are a great compromise between brain capacity and coding speed. It’s easy to get started, because you only need to learn one keystroke for a whole group of features. But since each item in the context menu is just another command, and many of them have their own shortcut keys (which are shown on the targeted context menus, unlike the main context menu), you can gradually learn the specific shortcut keys for the features you use all the time, and can access those features even faster.

Here’s an example of the “Navigate from Here” context menu, which you can access with Ctrl+Shift+G:

ReSharper's Navigate From Here targeted context menu

Being a context menu, it only shows you the commands that make sense based on the current cursor position. So if you’re on a class name, it will show you different options than it would if you were on a method name or a namespace name.

I haven’t used all of these options, but my current favorite is Inheritor. When you’re in code that’s calling a method on an interface, this will show you a list of all the classes that implement that interface method:

ReSharper's Navigate From Here - Inheritor, when applied to an interface method, shows all the methods that implement that interface method

It’s even cool enough that if those interface implementations are virtual, it’ll include the descendant classes that override that method. First-level overrides (classes that implement the interface) are shown in bold. Second- and later-level overrides (descendants that further override the method) are non-bold.

Gutter icons

I don’t use this one very often, because it only goes upstream, which is easy enough anyway; and you can do the same stuff with Navigate From Here. But it’s worth noting.

ReSharper shows gutter icons next to method declarations that have something to do with the base class (or an implemented interface). So if method Foo overrides a method in the base class, there’ll be one sort of icon. If it shadows, there’ll be a different icon. If it implements an interface, there’s an icon for that too.

ReSharper's gutter icons, showing an interface implementation, an override, and a shadowed method
ReSharper’s gutter icons. Shown are an interface implementation, an override, and a shadowed method.

(Come to think of it, I should start looking at these icons. The green “I” is a good visual indicator of which methods on a class come from an interface — not something you can otherwise tell just by looking.)

You can also click these gutter icons to jump to the relevant ancestor method. Sounds nice, but I hardly ever use it; I usually end up at the base class without trying! (Template methods are nice for removing duplication, but they can be a hassle for navigation.)

Go To Declaration

This is one of the keystrokes that changed when you installed ReSharper. What used to be F12 is now Ctrl+B; you can also Ctrl+Click on an identifier.

Apart from the keystroke, this works exactly like the Visual Studio version (jump to the interesting bit of code), with one difference. The difference comes up when you’re on an identifier that you don’t have source code for, such as something from a Microsoft assembly. VS and R# both show you a representation of the defining code, but…


ReSharper shows you the old Class Browser, which is klunky and a real pain to use:

ReSharper shows you the Class Browser

It actually does this for all its code-navigation features, not just Ctrl+click. For example, clicking a gutter icon can also land you in the Class Browser.

Visual Studio 2005, on the other hand, has a nifty new feature to show the class’s metadata as code (the “[from metadata]” feature), which replaces the Object Browser in all cases except those relating to ReSharper:

Visual Studio shows you the metadata as code, in a '[from metadata]' window

I think Visual Studio’s code view is far superior, for two reasons:

  1. The Class Browser sucks for navigation. For example, suppose I’m looking at Graphics.DrawImage (see the Class Browser screenshot, above) and I see that it takes a parameter of type Image. What if I want to jump to the Image class to see what methods it has? In the code view, it would be just a Ctrl+click away. But since ReSharper sticks us with the Class Browser, where the important information is split across three different panes, you have to know to first click on the right overload in the top-right pane, and then find the parameter type in the XML doc comments in the lower-right corner and click the hyperlink there. (For a long time, I didn’t even realize there was a way to jump to the parameter type using the Class Browser; I just figured it out while I was writing this.)

  2. The code view looks like code. It’s familiar; I’m used to it; I know exactly how to get around in it. Code is what I work with every day. Why on earth would a productivity tool like ReSharper choose to make me less productive by forcing me to learn another GUI for the exact same thing, when there’s already a better alternative?

I wish ReSharper used the new code view, and I’ve sent in a feature request to that effect. Their response was that, since you can still access VS’s “Go to Definition” from the context menu, they’re going to leave it the way it is. I find this disappointing, especially since it’s not just “Go to Declaration” that’s stuck with the klunky Object Browser — it’s everything in ReSharper related to code navigation.

(If you use ReSharper and this has been frustrating you too, let them know.)


ReSharper, day 10: Go To Type

Welcome to day 10 of my 31 Days of ReSharper.

Today’s topic is Ctrl+N: Go to Type.

ReSharper's Go To Type pop-up

You press Ctrl+N, and a little window pops up. You type in part or all of a type name, and it shows you a list of matches. Then you select one and press Enter, and it opens that file.

The only time you still need Solution Explorer is when you’re adding new files. Other than that, Ctrl+N is about all you need.

And it has shortcut features:

  • Search by title caps. If you type capital letters, it will try to match as if you were typing an acronym. So if you type MDT, it will match MyDataTable and MenuDropTag. (You can mix and match this with ordinary searching, so you could search for MDatT and find MyDataTable.)

  • Wildcards. You can type * to match zero or more characters, or + to match one or more characters. (This is a fileglob-style wildcard; it means “zero or more of any character”.)

Ctrl+N is in fairly direct competition with VSFileFinder; they both do pretty much the same “let me see a list of files matching a particular pattern so I can open one of them” thing. So I figured it’d be interesting to compare the two. Here’s how they stack up:

  • Stuff where ReSharper is definitely better:

    • VSFileFinder doesn’t support the title-caps thing that ReSharper has.

    • Ctrl+N already has a keybinding, whereas I’ve never been able to bind a keystroke to VSFileFinder that survived exiting and restarting Visual Studio.

    • Ctrl+N goes away as soon as you’re done with it, whereas VSFileFinder is a dockable window that keeps taking up space even after you’re done searching.

  • Stuff where VSFileFinder is a little better:

    • Neither tool requires you to know the entire name of the thing you’re searching for; they both let you specify parts of the name. However, VSFileFinder lets you specify those parts in any order; data table would match both DataTable and TableOfData. ReSharper is more limited; you have to specify the parts in the same order they appear in the type name (and you have to remember to type * between each one, instead of being able to just type a space in VSFileFinder).

    • Searching by substring is much easier with VSFileFinder. If you want to find all types that contain “Foo” anywhere in their name, you have to type *Foo in ReSharper, whereas with VSFileFinder you only have to type Foo.

  • Stuff where VSFileFinder is definitely better:

    • VSFileFinder makes it easy to open multiple files at once (precisely because the window is always visible and taking up space). This is a real win for tests — you can type Foo, see both “Foo” and “FooTests” in the list, and click on both of them to open both files. ReSharper doesn’t have this option.

That last item, in particular, illustrates that ReSharper and VSFileFinder are aimed at subtly different goals, and both tools have their place. (We have both of them installed on all of our development PCs.) But of the two, I usually end up using ReSharper’s Ctrl+N. That bit about having a keystroke bound is pretty persuasive.

If for some reason you don’t keep one class per file, you might also be interested in Ctrl+Shift+N, which searches on filenames (instead of type names like Ctrl+N does).

ReSharper, day 9: Parameter Info

Welcome to day 9 of my 31 Days of ReSharper.

Yesterday I talked about one Visual Studio feature (Find All References) that ReSharper replaced, enhanced, and changed the keystroke for. Today I’ll talk about another: Parameter Info, formerly Ctrl+Shift+Space.

ReSharper’s parameter info, accessible via Ctrl+P, shows all the overloads at once, instead of just one like Visual Studio’s:

Visual Studio parameter info
Visual Studio’s parameter info

ReSharper parameter info
ReSharper’s parameter info (click to enlarge)

If the method you’re calling doesn’t have any overloads, ReSharper’s parameter info is pretty similar to Visual Studio’s. But if you ever call overloaded methods (i.e., if you ever use anything in a Microsoft-provided assembly), the new parameter info has several decided advantages:

  • See where you’re going. Whenever I’m writing custom painting code in .NET, I have to face the dreaded Death by Overload. Seriously, what is up with System.Drawing? Some of the methods have 30 different overloads. When you know you want an overload that takes ImageAttributes (and of course they’re all way at the bottom of the list), it’s nice to be able to see lots of overloads at once.

  • You can use the cursor keys! When Visual Studio’s Parameter Info tooltip is visible, you can’t use the up and down cursor keys — VS hijacks them to mean “show the parameter info for the next/previous overload”. I’ve had to develop the habit of hitting “End” followed by “Right arrow” when I want to move to the next line (or “Esc” followed by “Down arrow”, but those keys are a lot farther apart…) But with ReSharper, you use Ctrl+P and Ctrl+Shift+P to cycle through the overloads, not up and down. So the cursor keys are available for actually moving through your code. Sweet!

  • Skip the ones that don’t apply. When you use Ctrl+P and Ctrl+Shift+P to cycle through the overloads, it will only step to the overloads that match the parameters you’ve already entered. For example, in the above code, I’m calling Graphics.DrawImage, and passing an Image and an int. If I press Ctrl+P again, it will skip the next overload in the list, because it takes a Rectangle as its second parameter — obviously not one I want, because I’m not passing a Rectangle. Instead, it will go two down, to the next overload that takes floats.

According to their Web site, ReSharper’s parameter info is supposed to show inapplicable overloads in gray. Unfortunately, this feature is broken in ReSharper 2.5.1 (I told support about it, and they said it’s supposed to work; they’re looking into it.)

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.

ReSharper's Find Results window, showing the filter menu and its options to show only read or write usages

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:

Visual Studio's Find Symbol Results window

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:

ReSharper's Find Results window, showing search results that are initially collapsed

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.

ReSharper, day 7: Code formatting

Welcome to day 7 of my 31 Days of ReSharper.

ReSharper has a great deal of support for code formatting. It basically falls into three categories: as-you-type, on-demand per file, and on-demand for multiple files.

Formatting as you type

This doesn’t sound new, does it? Visual Studio has had this for a while now. But of course ReSharper’s formatting options are versionable and sharable, so you won’t have some computers putting a space after typecasts and others removing it. This alone is a win.

Another nifty ReSharper formatting feature is in how it handles Enter inside empty curly braces. It’s a little better than the way Visual Studio handles the same thing, and ties nicely in with the automatic closing delimiters:

Starting out with an empty statement.
Type an open curly brace…
and press ENTER.

Formatting an entire file: Ctrl+Alt+F

ReSharper also has a command to reformat the entire source file you’re working on. If you press Ctrl+Alt+F, you’ll get the “Reformat Code” dialog box:

ReSharper's Reformat Code dialog box

Notice that it can do more than just tweak your whitespace. You can also tell it to fix some of those grays in your code. Optimize “using” directives” and Remove redundant ‘this.’ qualifier are pretty self-explanatory. Shorten references will change System.Drawing.Graphics to simply Graphics (adding the necessary using if needed).

We always check all of these boxes; we want our code as clean as it can get. It remembers your settings for next time.

Update: Maruis points out that Ctrl+Alt+Shift+F will do a silent reformat, without popping up the dialog, and just using whichever options you already had selected. Awesome! Thanks, Maruis!

Here are some other things ReSharper does when it reformats your code:

  • Adds explicit visibility specifiers. If you have classes with no visibility specifier, it will add the internal for you. Fields with no visibility get the private added. (As with everything in ReSharper, this is configurable. So if for some reason you wanted your code to be less readable, you could turn this option off.)

  • Puts simple getters and delegates on a single line. If the getter/setter/delegate body is a single statement (e.g., an assignment or a return), ReSharper will put it on a single line, along with the braces. So ReSharper would take this poorly-formatted code:

    public Color BorderColor {
            return _borderColor;
        set { _borderColor = value; Invalidate(); }

    and reformat it to look like this:

    public Color BorderColor
        get { return _borderColor; }
            _borderColor = value;

    Since Visual Studio 2005 doesn’t bother showing the extra layer of “collapse” plus signs for single-line getters and setters, this is a really nice feature.

Reformatting a project or solution

Finally, ReSharper has an option to reformat lots of files at once. Simply right-click on a folder, project, or solution, and select “Reformat Code”.

It may be obvious, but is worth noting anyway, that if you’ve made any other changes to your code, you should commit them to your source-control repository before you do this. Reformatting an entire solution is worthy of its own commit. It will change things, sometimes in ways you don’t want, and until you either change its settings, or adapt to its quirks, you’ll probably want the chance to selectively revert some of its changes.

Things it doesn’t get quite right #1: delegate indentation

By default, ReSharper indents your inline delegates a ridiculous amount. This is one of those where I think they got the default wrong: I want my code to follow normal indentation. I don’t want half of it ragged-center-aligned like this:

Block incrementer = delegate {
Block resetter = delegate {
                     i = 0;
                     j = 0;

I did finally find the way to fix this. The options for formatting anonymous methods are spread across two separate pages in ReSharper options: Braces Layout and Other. The “don’t indent a ridiculous amount” is on the Other page, and it’s called “Indent anonymous method body”. Turn it off, and set the brace option to “At end of line”, and you get something much nicer:

Block incrementer = delegate {
Block resetter = delegate {
    i = 0;
    j = 0;

Things it doesn’t get quite right #2: Xceed licensers

ReSharper tries to shorten qualifiers as much as it can. In suitably odd circumstances, it can decrease readability. Here’s one such case, and how we worked around it (which I think worked out quite well).

We use Xceed components in our software. One of our big frustrations with Xceed is the way they do licensing: they give you a license key, which is one of those ridiculously long strings of letters and numbers, and at runtime you have to write startup code that puts the key into a static property, like this:

Xceed.Grid.Licenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
Xceed.Editors.Licenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

Yes, you have to set a license key for each Xceed assembly you use. Otherwise, some of them will complain at runtime. (Some of them, oddly enough, won’t, but we set their license keys anyway, just to be sure.)

The oddness is with a class named LicenseKey in multiple different assemblies. ReSharper tries to shorten that like this:

using Xceed;
using Xceed.Grid;
Licenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
Editors.Licenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

Yuck. Here’s how we worked around it; ReSharper leaves this version alone:

using GridLicenser = Xceed.Grid.Licenser;
using EditorLicenser = Xceed.Editors.Licenser;
GridLicenser.LicenseKey = "LOTS-OF-LETTERS-AND-NUMBERS";
EditorLicenser.LicenseKey = "SOME-OTHER-LETTERS-AND-NUMBERS";

It’s a workaround for a tool limitation, but I think it actually reads better this way.

ReSharper, day 6: Shared options in the .resharper file

Welcome to day 6 of my 31 Days of ReSharper.

Sometimes we’ll end up with different IDE options on different computers. Since we all use all the machines in the bullpen, this tends to iron itself out over time, but it can be aggravating. It’s especially bad with code auto-formatting options, as files get reformatted automatically when we make seemingly unrelated changes like tweaking something on a design surface.

ReSharper to the rescue. Certain options are stored in a file in your solution directory: the .resharper file. Then you commit the .resharper file to your source-code repository along with everything else, and everyone on the team ends up using the same options.

There are two interesting things that get stored in the .resharper file: code-formatting options and templates.

Shared code-formatting options

ReSharper options screen, showing option to store code-style settings in revision control

As shown in the screenshot above (of ReSharper > Options > Code Style), ReSharper offers three different options for sharing code-formatting options:

  • Globally for the current user only. This is the default, and it’s what you want if you only have one developer on one machine.

  • Team-shared for the current solution. If you have multiple developers and only one Visual Studio solution, this is the option for you: everyone will use the same code-formatting options.

  • From external file for the current solution. This is a little more work to set up, but is what you want if you have multiple solutions in the same source tree (like we do).

To use the last option, you need to use the Export button to save your settings to an .xml file somewhere; and then specify the path to that file. If you’re sharing the settings among several solutions that are all part of the same source tree, then you probably want to specify a relative path.

Shared templates

It used to be that, whenever we added a new class to our solution, we had to spend a few seconds cleaning it up: fixing the class visibility, cleaning up usings we don’t need. When we wanted a new interface, we had to do “new class” and then change the “class” keyword to “interface”. Little things, but shouldn’t the computer be able to automate that stuff for us?

ReSharper lets you define several types of code templates: Live Templates (the ones with those different fields you can tab to and fill in), Surround With, and File Templates. All of these are configurable, and they’re all stored in the .resharper file, so again, they’re automatically shared among everyone on your team.

ReSharper ships with some sample templates you can look at, to see how it’s done. But they’re annoying, because they add a comment block at the top of each file with spaces for “Author” and “Date” — and why would you want to duplicate this information, when you could just look at your source-code repository and see who added the file? (My guess is that they make it annoying on purpose, so you’re sure to try your hand at making your own templates. We did.)

Making your own templates is easy, if a bit quirky. I’ll note that it’s important to click the “Available everywhere” hyperlink, and tell it that no, it’s only available for C# (if you don’t do this, it forgets to add a filename extension, and won’t format the file properly). Also, if you want special placeholders like $NAMESPACE$, be aware that it doesn’t recognize them by name; you have to click “Choose macro” in the “Template variables” grid, and select a macro from the list.

ReSharper's Available Everywhere hyperlink from the Edit Template dialog

ReSharper's Template Variables grid from the Edit Template dialog

ReSharper's list of available macros for use in templates