Case Study: Visual C Project Settings

For a specific example of configurability, let's take a detailed look at the Visual C++ Project Settings property sheet. This is a good example because it is about as complex as a configuration property sheet can get. And there's also plenty of room for improvement!

Multilevel Configuration

The Project Settings property sheet is a good example of a multilevel configuration user interface. It has three levels of configuration. At the highest level, you select the project configuration, typically Debug, Release, or All Configurations. At the next level, you select the specific items you want to change—typically the entire project, Source Files, Header Files, Resource Files, or any combination of these. The Project Settings property sheet then displays all the property pages that are common for the items you selected. Finally, you can change specific settings in each of the property pages.

While there are many different ways of handling multilevel configurations, this particular approach is effective because it is visible. That is, you can readily tell what you are doing by looking at what you have selected on the screen. By contrast, I once used a Brand B compiler that used a completely different technique. It let you determine settings for the project as a whole from the menu bar and settings for specific items from a context menu. While this technique doesn't sound all that bad, the problem is that it took me quite a while to realize that this was the way it worked. (Admittedly, this was a long time ago, before context menus were a standard Windows interface.) The program provided a subtle hint that the settings for an individual item were an override of the project settings, but somehow that didn't register immediately. As a result, I used the context menu to change what I thought were the project settings only to be confused when the changes I thought I made to the project didn't take effect. By putting the project settings and the individual item settings together in a single property sheet, the Visual C++ Project Settings makes this confusion impossible.

TIP

---

Make multilevel configurations visible. Put related configurations in a single property sheet.

Multi-Item Changes

Of course, the real objective behind the Project Settings property sheet is to be able to change settings, and having the ability to change settings for several items at a time is a valuable feature. When you select multiple items, the property sheet displays the property pages that are common to those items. Within each property page, each control shows the settings that are common as well. Check boxes are checked if all the items are checked, not checked if none of the items are checked, or displayed in a mixed-value appearance if the settings are mixed. The edit boxes display all the settings that are common to the selected items. Similarly, the combo boxes display a setting if all the items have the same setting; otherwise, they are blank.

This arrangement makes it easy to change multiple items at one time. Just select the items you want to change, and change them. A default-with-override scheme is used to make it easy to change settings at the project level. For example, if you set one file to compile at warning level 2 and then set the project to compile at warning level 4, the file retains the warning level 2. Ordinarily, this is what you want, but you will be in for a surprise if you select the entire project, change a setting, and think that you changed all the items in the project. In fact, you changed the default value only, and all the individual items with overrides maintained their overrides. If you want to change all items, you have to explicitly select the project and all the relevant items in the project before you make the change.

Displaying the common settings in an edit box is a powerful feature. If you select multiple source files, you can change a preprocessor definition common to all the files simply by changing the common setting. This technique has an interesting side effect. Since the edit box displays only what is common to the selected items, you can change only those settings that are common to those items. For example, let's say you want to completely clear the preprocessor definitions for a group of files that do not have completely common settings. The only way to do it is by clearing the items individually.

I find these rules interesting, and they allow the Project Settings property sheet to work more or less the way the user expects. The only problem I have is that these rules aren't explained anywhere. The Source File Options box helps somewhat by clearly indicating when a value is an override. However, I think there should be a help context for the entire property sheet to explain how the rules work.

TIP

---

If you set rules for using an interface, you need to explain them.