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:

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):

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):

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:

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

Comments

• Anonymous
  April 10, 2005
  Best of the Blogs - Ian Smith reviews the best of the last week's web development blogs so that you don't have to. Week ending 10th April 2005. Whidby, Visual Studio Team System, Visual Studio 2003, Training, Productivity Enhancers, Front-End Development and more...
• Anonymous
  June 13, 2009
  PingBack from http://hairgrowthproducts.info/story.php?id=7468