Typical Video Mode Problems

Generally, any element in your interface that is resolution-dependent is a source of video mode problems. Your goal is to make these interface elements resolution-independent, which in this context I define as looking and working well in all supported resolutions. The following sections present typical problems.

Graphics Problems

Bitmaps and icons are of fixed size, so they look different in different resolutions. For example, the following dialog box looks good in 800 × 600, Large Fonts:

But it doesn't look so good in 800 × 600, Small Fonts:

Here are a few suggestions for handling graphics in a resolution-independent manner.

Avoid using bitmaps and icons

Well, this is one way to avoid the problem. However, note that while bitmaps and icons are resolution-dependent, text (including symbols like Wingdings) and metafiles are not. A bitmap containing text is always going to give you more problems than straight text itself.

Leave plenty of space

Realizing that the origin of bitmaps and icons is stationary but that they grow or shrink on the right and bottom, you can make your graphics' resolution dependence less noticeable if you place them to the top and left of your windows and dialog boxes and leave plenty of space around them. This is at least one reason why icons in an About box are usually in the upper left corner. Placing a bitmap or icon in the lower right corner of a dialog box is asking for trouble.

Scale your graphics

Of course, if the above two approaches don't work, you should scale your graphics (by using the StretchBlt function instead of the BitBlt function) so that they size proportionally to your windows or dialog boxes. If scaling doesn't look good, you could create the graphics at run time by dynamically rendering them into bitmaps of the correct size. Alternatively, you could create different-sized graphics for different resolutions and select the best graphic at run time.

Window Layout Problems

Since the number of windows you can display on the screen and the amount of information displayed in a window are resolution-dependent, handling the window layout of your program in a way that is reasonably resolution-independent is particularly challenging. The next two sections describe some typical problems.

MDI programs

The good news is that MDI programs allow users to lay out document windows as they choose. As long as your program gives the user plenty of flexibility in the screen layout and it has features to save and restore these settings, your users should be happy. The bad news is that MDI programs often have docking windows and complex toolbars and status bars that complicate matters.

MDI windows, especially docking windows, should be created with an initial size that scales proportionally with its contents. Typically, this means adjusting the window's size to the size of its text. For example, a window that docks on the left-hand side of an MDI program should set its width with code similar to the following:

windowSize.cx = max(20 * fontSize.cx, appSize.cx / 4);

This code makes the docking window wide enough to display 20 average characters (which, for the sake of argument, is the normal size of its contents) or at most a quarter of the width of the program window in lower resolution modes to prevent the docking window from taking up too much of the MDI client area.

The complexity of many MDI program toolbars means that the user should be able to create several independent toolbars and the toolbars should be movable and configurable. An application like Visual C++ would not be effective with a single static toolbar. On the other hand, Microsoft Outlook Express has a fairly simple toolbar, so a single static toolbar works fine.

The status bar should have at least one pane that stretches to fill any unused space (that is, have the SBPS_STRETCH attribute in MFC's CStatusBar class). Furthermore, you need to be careful with the text you place in the status bar. If you have lengthy text, you might need to have a short and long version of the text and display the long version only when you have the room. This is worth the extra effort, since the whole point of the status bar is to help the user and chopped-off text isn't especially helpful.

SDI programs

SDI programs suffer from basically the same problems as MDI programs but to a much smaller degree. Generally, SDI programs are much more resolution-independent than MDI programs. While you don't have to worry about laying out windows, you do have to worry about sizing splitter windows, as well as toolbars and status bars. You can use the suggested MDI solutions when needed.

Dialog Box Problems

Regardless of the minimum video mode you choose to recommend, you need to make sure that all your dialog boxes fit within at least 640 × 480 for your program to be minimally functional in this mode. A classic example of a dialog box that doesn't fit within 640 × 480 is the original Windows NT 4.0 Display Control Panel applet. (Note that this problem was fixed by a service pack.) It is so large that neither the title bar nor the OK, Cancel, and Apply buttons appear on the screen. This means that you can change your settings, but good luck actually making the change since you have to somehow click the OK button or the Apply button without seeing it or moving the cursor to it. (You can do it by using the keyboard but not the mouse.) Note that since the title bar is not visible, you cannot use the mouse to move the window to see the buttons. Also, it's unfortunate that the dialog box used to change video modes doesn't display in all video modes, as anyone who has ever tried to change the video mode in 640 × 480 in the original Windows NT 4.0 can attest.

TIP

---

Regardless of your minimum recommended video mode, make sure all dialog boxes fit within a 640 × 480 screen resolution.

However, there is a far more subtle problem with dialog boxes that happens a lot. Have you ever seen a dialog box that looked like this

when it was supposed to look like this?

Why does this happen? The problem is the result of a conspiracy between fixed control sizes (in dialog box units in Visual C++ or twips in Microsoft Visual Basic) and static text controls. For Visual C++, dialog box units are the unit of measurement used in dialog box templates to determine the size of dialog boxes and their contents. The dialog box unit is based on the size of the text used in that dialog box, specifically one-fourth the width of the average character and one-eighth the height. While dialog box units are generally a good thing and make dialog boxes resolution-independent, they interact with static text controls in an interesting way. Note that Visual Basic has the same problem but with different units.

Static text controls are used to display text in a dialog box. They are multiline controls, so they display as much text as they can, perform a line break, and continue the text on the next line. But what if the control is only one line high? The line break still occurs, so the remainder of the text is displayed on the next, albeit invisible, line. This is why the whole last word dropped in the first of the two dialog boxes above.

But static text controls are sized using dialog box units, so how can this happen? The problem is that while the dialog box and its controls are scaled exactly according to the dialog box units, the specific text in a static control is not. Why? Because the specific text in a control does not necessarily scale exactly the same as average text. Some text might scale to the average, some text might be larger (for example, WWW), and some text might be smaller (for example, an ellipsis). So, although dialog box text can look good when you initially create the dialog box template, it might get chopped off in other video modes.

One final detail to remember is that dialog box units are not pixels—in fact, a dialog box unit is often about 1.5 pixels—so you should not try to achieve precise alignment in dialog box templates. For example, any effort to align two controls exactly one pixel apart is doomed to failure. It might look good in one video mode, but chances are it won't in other video modes.

Dialog Box Solutions

Given the fact that you cannot be sure that the static text in a dialog box will display properly in all video modes, and given the 48 possible video modes, what can you do to make sure your static text displays properly?

First, make sure your static text controls have plenty of room to grow. While you can try to make your static text controls exactly the right size, there is no downside to giving them plenty of room to expand. This practice helps you maintain the resources (especially if you often edit resources directly with a text editor, which I sometimes do), and it also helps if you localize your product.

TIP

---

Always give your static text controls room to grow to avoid resolution-dependent problems.