EDN: ESRI Developer Network
This topic is relevant for the following:
Product(s): ArcGIS Desktop: All
Version(s): 9.0, 9.1, 9.2
Language(s): VB6, VC++
Experience level(s): Intermediate to advanced
In this section:
Consistent user interfaces not only help your components look professional—they help your users navigate efficiently, increasing the usability of your customizations.
Published guidelines are available for windows applications—the user interface guidelines in MSDN will help your dialog boxes achieve the Windows 'look and feel'. In addition, the book The Windows Interface: An Application Design Guide will give you complete information on the Microsoft approach to user interface design. See the bibliography for details of these references.
In addition to those references above, you may want to review the standards below, which have been used throughout ArcGIS. Based on the guidelines for Windows applications, these property page standards should help you ensure your dialog boxes are visually and textually consistent and logical as well as have logical keyboard access.
The guidelines are also useful for other user interface items, such as dialog boxes and applications, not just property sheets and pages.
Both the Microsoft standards and the standards below use Dialog Box Units (DLUs) to define the size and location of the controls in a dialog box.
A DLU is a device-independent unit, based on the current system font.
One horizontal dialog box unit is equal to one-fourth of the average character width for the current system font. One vertical dialog box unit is equal to one-eighth of an average character height for the current system font. The default Windows system font is 8-point MS Sans Serif, which gives a vertical dialog unit of approximately 22 twips.
Using DLUs allows dialog boxes to be sized correctly if the system font on the user's machine (where the dialog box is displayed) is different from that on the development machine (where the dialog box was laid out).
Laying out a dialog box in DLUs in VC++ is simple—DLUs are the units used by the VC++ form editor.
For VB developers, however, the situation is somewhat more complicated, as the VB form editor does not include a ScaleMode of DLUs. You may want to use one of the following to estimate a DLU:
Dialog boxes and controls should generally be sized as follows:
| Control | Height (DLUs) | Width (DLUs) |
|---|---|---|
| Small dialog box Medium dialog box Large dialog box |
188 215 218 |
212 227 252 |
| Command button | 14 | 50 |
| Option buttons, check boxes | 10 | as required |
| Text boxes | 14 | as required |
| Other text and labels | 8 per line of text | as required |
| Dropdown combo and list boxes | 10 | as required |
The default height for most single-line controls is 14 DLUs. Controls that contain text, such as edit boxes, option buttons, check boxes, and labels, should be sized horizontally as required to display their contents and align correctly with other controls in the dialog box.
Controls within a dialog box should be at least 4 DLUs apart. Generally you should lay out controls in a dialog box starting from the upper-left corner, using a 7 DLU margin between the edge of the dialog box and the contained controls. Controls should generally be left-justified.
Related controls in a dialog box should be grouped together. You can group controls by using group box controls, separators, or by altering spacing. If using group boxes, use a 4 DLU margin between the controls and the edge of the group box. Increase the margin to 7 DLUs at the bottom and 14 DLUs at the top of the group box, to allow for the box title. Left-align the controls with the box title text.
If the first control is a label (for example, accompanying an edit box), a smaller margin of 11 DLUs may appear more consistent.
Make sure that if a particular command button applies only to a particular field that it is grouped with that field to avoid confusion.
Separators should be used sparingly—only where group boxes would be too overwhelming—but there still is a need for grouping related items. Often, increasing spacing around the related elements can be effective instead.
These controls should be left-aligned (right-aligned for right-to-left languages), with accompanying text labels left-aligned, placed to the left or above the control. Note that dropdown list boxes should generally have their accompanying text label above the control, although the label may appear to the left if it can be aligned with other controls.
If an accompanying label is to the left of a box control, align the height of the label with the text displayed in the text box.
OK and Cancel buttons should be left-aligned if vertically stacked, and top-aligned if placed side-by-side.
Different types of dialog boxes require different placement of OK and Cancel command buttons. A property sheet will always have OK, Cancel, and Apply placed at the bottom of the sheet below the property pages.
Standalone dialog boxes can have OK and Cancel aligned horizontally in the lower right corner or stacked on the top right corner. In either case, the default button is typically the first button in the set, for example, the OK button, with the Help button being last if it is present. OK and Cancel should always be next to each other.
Command buttons on a tab control within a dialog box should only apply to the controls on that particular tab; whereas buttons outside the tab control apply to the entire dialog box.
All controls should have Help Context IDs. See the 'Implementing help for custom classes' section for more information.
Text on command buttons, title bar text, icon labels, and tab titles should use conventional title capitalization—capitalize the first letter in each word. Articles (a, an) and prepositions (on, at, in, and so forth) are not capitalized unless they occur at the beginning or end of the text. If a word is generally capitalized a certain way, use this method (for example, ArcGIS, INFO database).
User-defined text should remain as the user specifies it, regardless of case.
Field labels—for example, option button labels, check boxes, text boxes, group boxes, and page tabs—should use sentence-style capitalization.
You should always ensure you set an appropriate tab order for your form—this can easily be neglected during development but is simple to do and makes it so much easier for users to navigate your dialog box quickly and efficiently.
Set the order such that the user can move through the dialog box from left-to-right and top-to-bottom, which allows the user to progress through grouped controls in a logical order. Command buttons, such as OK and Cancel, are usually the last in the tab sequence. Label text should not generally take part in the tab sequence, but you should bear in mind the rules for Access Key use described in the following section.
Because option buttons typically function as a group, you may want the tab order to move focus to the currently selected option in that group, not between individual options. Arrow keys can instead be used to move between options in a group. Check boxes, however, should have separate tab order settings.
If you're developing in VC++, you can set the tab order by selecting Tab Order from the menu or by pressing CTRL+D and clicking the controls in the correct order.
VB Developers should set the tab order by setting the TabIndex property of each control individually, then running the ESRI Align Controls With Tab Index VB add-in, which is part of the ArcObjects Developer Kit.
Access keys allow the user to set focus to any control in the dialog box by pressing and holding the ALT key in combination with another alphanumeric key designated as the access key for that control.
In both VC++ and VB, access keys are designated as the character after the ampersand (&) in the control's text or caption. The ampersand is not visible at run time, when instead the access key is shown underlined.
Note that for combinations of controls, such as a label and edit box control or a spin button and edit box, you can set the access key typed in the label control to set focus to the accompanying control, which has no text. You do this by ensuring the edit box control has a TabIndex value one greater than the label control and setting the TabStop property of the label control to False.
Ensure you do not specify the same access key twice for a dialog box. This requires particular care for property pages, which take part in a larger property sheet—for example, avoid using "a" or "A" as an access key because the property sheet will use "A" for the Apply button.
Message boxes should be used in situations where the user must confirm an action or command and must communicate the requirements effectively. Used inappropriately, they can interrupt the flow of work—it is often better to avoid using message boxes if possible.
An appropriate use would be to confirm a delete that cannot be recovered. An inappropriate use would be to inform a user that an option is unavailable—disabling commands may be a more effective way to achieve this.
A message box should include four things:
| Icon | VB MsgBox Icon constant / Windows API MessageBox constant | Context |
|---|---|---|
 |
vbInformation MB_ICONINFORMATION |
Alerts the user to a condition or situation that requires a decision before proceeding, especially potentially destructive irreversible actions. |
 |
vbExclamation MB_ICONEXCLAMATION |
Used to show information about results of a command. The only button should be OK. |
 |
vbCritical MB_ICONSTOP |
Informs the user of a serious problem that requires correction or intervention before work can continue. |
 |
vbQuestion MB_ICONQUESTION |
Informs the user that a response to the statement is needed before execution can continue. It may have one or more buttons for the user to click. |
Your descriptive text should be clear and concise, avoiding the overuse of technical jargon. Try not to exceed three lines of text, providing only the necessary information, but enough to adequately describe the situation. If there is a problem that needs to be solved, suggest a solution and alternatives. Use complete sentences.
The Cancel button can often be used to interrupt a task in process. Only use the Cancel button if your code then ensures the application is returned to its previous state; otherwise, use the Stop button.
See also Property Pages