Editing Type Members Using the Class Details Window

If you’ve used the beta version of the Class Designer, you’ve probably noticed the Class Details Window (if for no other reason than it pops up by default when you open the designer for the first time). If you haven’t tried Class Designer yet, here’s what it looks like, assuming you have a class named DriveInfo selected in the Class Designer:

Class Diagram before refactoring.

If you’re curious about what you can do with this window, read on!

What is this window for?

Its main purpose is to support class building and editing scenarios by letting you edit class members. When you’re designing a class library or application, for instance, it’s often useful to sketch out not only the classes involved, but also the APIs they expose. Or, you may find yourself looking at a diagram and thinking that the type a particular parameter should really be a user-defined structure, rather than a simple integer. The CDW enables both of these cases (and more!) without ever leaving the diagram. To get started, just click on one of the <add> nodes shown above, type in the name of a new member, and press return. Voila, a new member is added to the class!

Well, that’s sort of cool, but really, why wouldn’t I just type my members in the code editor?

This is exactly the question we asked ourselves before designing this window. We thought we could enrich the class design experience if we provided a complete member editing experience without the disruptive “context-switch” to code, but realized that unless it compared favorably with the VS code editing experience users expect, they wouldn’t give it a second thought. So, here are a couple features we came up with:

1. Intellisense in the Type column (pretty much a no-brainer):

Class Diagram before refactoring.

2. Special keybindings. The CDW supports the keyboard navigation functionality that you’d expect from a grid-type control, such as TAB, Shift-TAB, and arrow keys to move between cells. But we also added some special keybindings to make the CDW experience more like typing code. With the cursor in the “<add method>” cell, try typing the following “GetDriveByName DriveInfo (name string)”. Whoa. For those of you without Class Designer in front of you, here’s what happens in the CDW (images progress left-to-right then top-to-bottom):

Class Diagram before refactoring.

3. Rename refactoring. As with elsewhere in the Class Designer, changing the name of a member in the Class Details Window invokes the Whidbey rename refactoring feature.

All right, but is it really worth all that precious screen real estate?

Here are a couple more features that might convince you:

Class Diagram before refactoring.

1. Support for hiding/showing members on the design surface. If you’re only diagramming a particular aspect of a class (for documentation purposes, perhaps), you may want to hide unrelated members. Using the Hide column in the Class Details Window is a lot less tedious than right-clicking on each member on the design surface and selecting the “Hide” command from the context menu.

2. Integrated support for XML comments. The Summary column lets you view and edit commonly used documentation tags.

Ultimately, I think the users who will find the Class Details Window most valuable are those who would really like to avoid switching to the code editor when while wearing their design “hats”. We’re betting that the majority of our users fall into this category. As always, we’d welcome any feedback and opinions.

Thanks,

Grayson Myers

Visual Studio Class Designer Team