Common Desktop Environment: Style Guide and Certification Checklist

Chapter 7 Common Dialogs

Use dialog boxes (secondary windows) to support user tasks that require detailed interaction from the user and that do not lend themselves well to direct manipulation in the main window. For example, you may not require a dialog box to support the task of setting a margin if the task can be performed by directly moving a margin stop on a ruler. On the other hand, you might require a dialog to support formatting a document if the task requires that the user specify several formatting options.

Dialog Box Design and Layout

Optional 

ct: 

Keep the size of your dialog boxes to a minimum. Remember that on low-resolution displays, dialogs may take up most of the screen real estate, and may even run off the edge of the screen if not designed correctly. 

Optional 

cu: 

Avoid complexity in your dialog boxes. If your dialog box must support many functions, consider using an expandable dialog box (see "Expandable Windows" on page 291), or use more than one dialog in a nested fashion. 

Optional 

cv: 

Avoid the use of resize handles in your dialog box. However, you may use resize handles when resizing is useful in allowing users to see more information; for example, when your dialog contains a scrolling list that is likely to be quite long, and users will frequently need to search the list. 

Recommended 

cp: 

The title of dialog boxes used within your application adheres to the conventions listed in Table 10-3 

Required 

cq: 

Every dialog box in your application has at least one button that either performs the dialog box action and dismisses it or dismisses the dialog box without taking any action. 

Recommended 

cr: 

If your application uses common dialog box actions, the actions have the following specified functionality and labels: 

 

 

Label 

Functionality 

 

 

Yes 

Indicates affirmative response to a question posed in the dialog box. 

 

 

No 

Indicates negative response to a question posed in the dialog box. 

 

 

OK 

Applies any changes made to components in the dialog box and dismisses the dialog box. 

 

 

<command> 

Applies any changes made to the components in the dialog box, performs the action associated with <command>, and optionally dismisses the dialog box. 

 

 

The <command> button should be used in lieu of OK, Yes, or No as a button label when it provides more meaning to the user as to the action that will be performed when that button is clicked. 

 

 

Apply 

Applies any changes made to components in the dialog box and does not dismiss it. 

 

 

Retry 

Causes the task in progress to be attempted again. 

 

 

Stop 

Ends the task in progress at the next possible break point. 

 

 

Pause 

Causes the task in progress to pause. 

 

 

Resume 

Causes a task that has paused to resume. 

 

 

Save As Defaults 

Saves the current settings as the default settings that will appear the next time the window is displayed. The settings are not applied to any selected object and the dialog box is not dismissed. 

A Save As Defaults button should be provided if it is expected that a user would want to use different default values for a set of controls within a dialog box than those that you provide as the factory settings. For example, a Save As Defaults button might be provided in a "New <object type>" window, allowing the user to indicate that whenever a new instance of that object-type is created, the current values should be displayed as the defaut settings instead of the values given by the application. 

 

 

Reset 

Cancels any changes that have not yet been applied by your application. The controls within the dialog box are reset to their state since the last time the dialog box action was applied. If no changes have been applied within the current invocation of the dialog box, the controls are reset to the state when the dialog box was first displayed. 

 

 

Reset to Factory 

Cancels any changes that have not yet been applied. Components in the dialog box are reset to their default state and value as specified by the vendor that delivered the application (that is, the controls are restored to the original factory settings). 

 

 

Cancel 

Dismisses the dialog box without performing any actions not yet applied. 

 

 

Help 

Provides help for the dialog box. 

Recommended 

cs: 

Any visible control that is not currently active or whose setting is currently invalid is dimmed. 

Dimmed controls cannot be activated by the user and should appear only when the inactive state is short-term (that is, there is something the user can do within the application or the desktop environment to make the control become active). When the control is persistently inactive (because of the current configuration of the application or system, or a particular set of companion software is not currently installed), the control should be removed rather than dimmed. 

Optional 

cw: 

Every dialog box in your application has exactly one default button that is activated when the Return key is pressed. 

The default button should be associated with the most likely response from the user and should not be potentially destructive or irreversible. Some applications may have dialog boxes that do not reveal a default button until a specific set of fields has been filled out or otherwise manipulated. 

Optional 

cx: 

If a dialog box displayed by your application has controls that are considered to be advanced features, use an expandable dialog box, or use a multiple page dialog box that provides a <category> option menu that allows a user to navigate to each page. 

Controls that relate to advanced features should not be displayed with the set of options initially displayed to the user. The typical user should be presented with only those options that are necessary to use the basic functionality of the application. Users looking to access advanced functionality within the dialog box may use the Category option button (see Figure 7-1). If the number of advanced controls is very few, or the settings for these controls are highly related to the settings of basic controls displayed in the dialog box (that is, the settings of the advanced controls change when the user changes settings for basic controls), you might choose to provide an expandable dialog box (see the section on Expandable Windows and Dialog Boxes). 

Figure 7-1 An example of using a Category option menu in a dialog

Graphic

Optional 

dl: 

Controls within your dialog box are placed in a left-right, top-down layout based on the order in which the user is expected to fill out or choose options within the dialog box. 

This assumes that your application is being designed for a left-to-right language environment. Alternate design approaches may be necessary for other locales. 

Required 

dm: 

Push buttons that affect the dialog box as a whole, either by modifying its contents or layout, invoking the action of the dialog box, or dismissing the dialog box, are located at the bottom of the dialog box. 

In general, there should only be one row of buttons at the bottom of a dialog box. If your application has dialog boxes that contain several global buttons, it may be necessary to create two or more rows of buttons at the bottom of the dialog box. The last row should contain the standard dialog box buttons (OK, Reset, Cancel, and Help). If a dialog box contains buttons that are not related to the dialog box as a whole, but instead, relate to a specific control within the dialog box, the buttons should be located near the control to which they relate. 

Required 

dn: 

If your application provides an Apply button within a dialog box, it also provides an OK button or command button that performs the dialog box action then dismisses it. 

Optional 

do: 

Your application does not use cascading buttons within dialog boxes unless there is absolutely no other design alternative that can be used without a negative impact on the layout of your dialog box. 

In general, cascade buttons should only be used within menus and menu bars. You should avoid their use in all other locations unless absolutely necessary. 

Dialog Box Placement

Recommended 

al: 

A secondary window is placed by the application relative to the associated primary window. It should be placed close to, but not obscuring, the component that caused it to be displayed and the information that is necessary to interact with the dialog box. 

Some suggestions are given in section 6.2.4.3, "Determining Dialog Box Location and Size," of the OSF/Motif Style Guide, Revision 1.2. Additional or modified recommendations include: 

Optional 

am: 

If a dialog box does not relate to specific items in the underlying window, it should be placed below the menu bar (if there is one) and centered (horizontally) over the work area. 

Recommended 

an: 

If a secondary window is allowed to be stacked below its associated primary window (not constrained to stay on top of the primary window), it should be placed such that it is not completely covered by the primary window. This recommendation takes precedence over other placement recommendations. 

Recommended 

ao: 

If a menu or dialog box is already on display, reinvoking the command that caused it to be displayed automatically brings that window or menu to the front of the window stack without changing its position on the screen. 

Dialog Box Interaction

All of the navigation and selection guidelines that apply to applications in general should apply to your dialogs. In addition, as you design your application-specific dialog boxes, you should follow these guidelines to ensure maximum usability and accessibility.

Required 

en: 

When your application displays a dialog box, it places the input focus at the first text field into which the user is allowed to type an entry, or at the first control within the dialog box with which the user should interact. 

Input focus should always be placed at a predictable and intuitive location. The user should not be forced to set focus at the control most likely to be used when the window is displayed. 

Recommended 

eo: 

As the user presses the Tab key within dialog boxes of your application, the input focus moves to different controls within the window in a left-right, top-down order. 

This assumes that your application is being designed for a left-to-right language environment. Alternate design approaches may be necessary for other locales. 

Required 

et: 

Dialog boxes displayed by your application never block input to other applications within the desktop (that is, they are not system modal) unless it is absolutely essential that the user perform no other action in the desktop until the user responds to the dialog box. 

Applications must allow the user the freedom to access information and tools within the user's desktop environment. Only in the most dire circumstances should an application ever block access to other applications and services within the environment. 

Recommended 

eu: 

Dialog boxes displayed by your application never block access to other functionality within the application (application modal) unless it is essential that the state of the application remains unchanged until the user responds to the dialog box. 

Required 

6-18 

A warning dialog box allows the user to cancel the destructive action about which the dialog box is providing a warning. 

Expandable Windows and Dialog Boxes

This section describes a standard method for providing expandable windows or dialogs in Common Desktop Enviroment. Expandable windows allow users to selectively display advanced or application-specific functionality in a separate portion of the window that is normally not visible when the window is initially displayed. Users can choose to display the entire window, or only the core functionality, according to their own needs and preferences. Applications can implement expandable windows fairly easily using existing toolkit components.

Use expandable windows only when your application needs to present a limited set of additional dialog box options. Consider using an alternate method if your dialog would grow unmanageably large, for example, larger than a typical low-resolution display could handle. Keep in mind also how your dialog will expand when translated into other languages. An alternative method for expandable dialogs is to use a multipage dialog and provide a Category button for switching pages.

Guidelines for Expandable Windows and Dialog Boxes

Recommended 

fn: 

The primary pane of the dialog box or window should contain all of the controls needed to complete the task. This should include all critical and frequently used functionality. 

Recommended 

fo: 

It is assumed that infrequently used features are placed in the secondary pane. The core functionality of the application should not depend on any controls placed in secondary panes. 

Required 

fp: 

Command buttons are aligned along the bottom of the dialog box. When the window is expanded to show a secondary pane, then buttons are moved to the bottom of the secondary pane. See Chapter 6, "Application Design Principles" for information about layout of action buttons in dialog boxes. 

Recommended 

fq: 

If important controls must be placed in the secondary pane, the application can specify that the window in question should be displayed in its expanded state by default. Users should still be able to shrink the window by pressing the Contract button. 

Components of Exapandable Windows

To create an expandable window or dialog box, use the standard Motif widgets in conjunction with state variables and some simple rules that govern its behavior. In addition to the application-defined controls and displays that make up the content of the window itself, use a primary and secondary pane in the following way.

Primary and Secondary Panes

The primary pane should contain the core or base functionality required by nearly all end-users of the application. The primary pane is a standard Motif container that is the main component of the window or dialog. Only the primary pane is visible when the expandable window is initially displayed. An "expand button" allows the user to display a secondary pane providing access to the full functionality of the window or dialog. (See Figure 7-2.)

Figure 7-2 Calendar Appointment Editor primary pane with Expand button (More)

Graphic

Expanding the Secondary Pane

The secondary pane provides space for additional options or advanced functionality without increasing the difficulty of the core functionality in the primary pane. The secondary pane can be expanded in a vertical or a horizontal direction. To determine the appropriate direction in which to expand, consider the following questions:

Recommended 

fr: 

The secondary pane should expand in the direction most consistent with users' expectations, the reading pattern of the language in which it will be displayed, and the content of the information displayed. 

Recommended 

fs: 

If possible, the panes should have the same default width. 

Required 

ft: 

A separator should be used to separate the primary pane from the secondary pane. 

The user needs to have clear visual feedback as to which elements are part of the primary pane and which elements are part of the secondary pane of the expandable window.  

Resizing the Expanded Window or Dialog

Required 

fu: 

If a window is resizable, any sizing changes should be allocated to the pane containing scrolling lists or text fields whose displayed length is less than their stored length. If both panes contain scrollable controls, size changes should be distributed evenly between the two panes. If neither pane contains scrollable controls, the window should not be resizable. 

Figure 7-3 Calendar Appointment Editor with expand button (Less) and primary and secondary panes

Graphic

Expand Button

The expand button is used to display the secondary pane. The expand button is a standard Motif drawn button with a label that changes depending on the state of the window. The button labels for the two states should tell the user what will happen. For example, the button might say Options when the window is closed and Basic when the window is open. Clicking the Options button displays the bottom pane; clicking the Basic button hides the bottom pane. Labels should be opposites such as Expand and Contract, More and Less, or Basic and Options.

Required 

fv: 

The expandable window should have one button that changes its label based on the state of the window. 

Required 

fw: 

The expand button should have two labels that reflect the two states of the expandable window accurately. The current label should indicate to the user what will happen if the user clicks the button. 

Examples of possible labels are Basic and Options, Expand and Contract, and More and Less.  

Optional 

fx: 

The expand button may contain a graphic in addition to the label. This graphic should indicate the direction in which the window will expand or contract. 

Placing the Expand Button

Recommended 

fy: 

The button should appear in the lower left-hand corner of the window or dialog box for expansion in the vertical direction and in the lower-right hand corner for expansion in the horizontal direction. 

Required 

fz: 

If the window or dialog box contains a scrolling list positioned to the far right side of the pane, do not align the drawn button with the scroll bar. For example, the button should be aligned with the list, not the scroll bar. 

Window State

Required 

ga: 

Applications must remember the state of each window or dialog box (expanded or not expanded) independently (not collectively). The state should be changed only by the user and should always be preserved until explicitly altered by the user. 

Recommended 

gb: 

Applications should remember the state of each expandable window or dialog box across sessions, so that users don't have to manually configure the expandable windows each time the application is run. 

If appropriate, applications can provide a mechanism to allow users to set the state of an expandable window on a global basis in the application. This would be part of the application's Options.  

File Selection Dialog Boxes

The Common Desktop Enviroment file selection dialog box is a subclass of the Motif file selection dialog box that has enhancements for improved usability. As long as your application uses the standard Motif file selection dialog box calls, the Common Desktop Enviroment enhanced version will appear in the Common Desktop Enviroment environment. There are additional guidelines to follow to make your dialog consistent and easy to use. Use the file selection dialog box whenever your application supports a task that involves choosing a file or directory. Examples are: Open, Include, Save As, and Copy To.

Contents

required 

7-10: 

If your application uses a file selection dialog box, it contains the following components: 

  • A directory Text component showing the current directory path. The user can edit the directory Text component and press <Return> or <Enter> to change the current directory.

  • A group of push buttons, including a command button, and Update, Cancel, and Help buttons. The command button is typically labeled Open or Save, but if there is another label that better describes the resulting action (such as Include), that label should be used. Activating the command button carries out the corresponding action and dismisses the file selection dialog box.

  • For applications that allow saving to different formats, an option button allowing users to specify the format when saving a file.

  • A file name Text component for displaying and editing a file name. This component is optional when the file selection dialog box is used to choose an existing file or directory.

Figure 7-4 Example of an Open file selection dialog box

Graphic

Required 

7-17: 

The file selection box displays the contents of a directory in the contents list when the file selection box is initialized, when the user presses Enter or Return in the directory text component, and when the user opens a directory in the contents list. The contents list is updated each time the contents of the directory changes. 

This specification ensures the consistent operation of a directory and file search in a file selection dialog box. 

Optional 

ht: 

Directory and file name lists should be presented alphabetically, case insensitive. The first item on the directory list should be the parent directory and it should be labeled "..". 

Recommended 

de: 

The file selection dialog box should not display hidden (dot) directories or files, unless your users depend on using these types of files. If your application does support displaying hidden files, you should supply a check box allowing users to toggle between showing and not showing hidden files, or else allow users to toggle between showing and hiding files at a global level in your application. 

Recommended 

df: 

The file selection dialog box should not show the full path names for files and directories, but should only show the relative names, except for the directory text field 

The global Common Desktop Enviroment setting should be: 

XmFileSelectionBox.fullPathMode: false

Unless your application overrides this behavior, your file selection dialog box should not show full path names in the list boxes. 

Required 

dg: 

In general, the file selection dialog box should recall the directory location that was previously set by the user. 

For example, if the user brings up Save As and navigates to /users/jay/letters to save the file, the next time the user brings up Save As, the file selection box should be in the directory /users/jay/letters. This information, however, should not be recalled once the user has closed the primary window, but should resort to the default directory.

If your application supports multiple primary windows, each window should recall the directory location that was set for that window. 

File Selection Dialog Box Behavior

Optional 

hq: 

The file selection dialog box should come up in a directory that makes sense for the task. For example, when saving a new file from an editor, the file selection box should come up in the user's home directory. If the user navigates to some other directory within the file selection box, the application should remember that directory the next time it is brought up. 

Optional 

hr: 

Users should never be allowed to overwrite an existing file through the file selection box without a warning dialog box prompt. 

Optional 

hs: 

Keyboard focus should be placed in the file name field each time users bring up a file selection dialog box. 

Labeling

Optional 

hu: 

Labels should be clear. In the English language, use the following labels for the file selection dialog box fields and lists: 

 

 

Component 

Label 

 

 

Directory text field 

Enter Path or Folder Name 

 

 

Filter text Field 

Filter 

 

 

Directory list 

Folder 

 

 

Contents list 

Files 

 

 

File text field 

Enter Filename:* 

Optional 

hv: 

Optionally, application developers can make this label more instructive and specific, such as Enter File to Open for Open dialog boxes. (see following sections for specific recommendations). 

These labels should be the default labels. If they are not set by default, you need to set them via resources in your application's app-defaults file. 

Recommended 

he: 

When the file selection box is used to specify an existing file (for example, to open a document), the command button is normally labeled Open and it should be the default action. 

Required 

hj: 

When the file selection dialog box is used to specify a new file name (for example, a Save As dialog box), the command button is normally labeled Save and is the default action. This specification ensures the uniform appearance of a file selection box across applications. 

Button Activation

Recommended 

hf: 

If the Update button is activated while a directory is selected in the contents list, the directory is opened, its contents are displayed in the contents list, and the directory text is updated. 

Required 

hg: 

If the Open button is activated while the appropriate file is selected in the contents list, the file is utilized by the application and the file selection box is dismissed. 

Selection and Navigation

Required 

7-12: 

Double-clicking BSelect on an item in the contents list selects that item and activates the default action. In all cases, double-clicking BSelect on a directory in the contents list opens that directory and displays its contents in the contents list (the default action is Open). 

  • When the file selection dialog box is used to choose an existing file, double-clicking BSelect on an appropriate file in the contents List chooses that file and dismisses the file selection dialog box (the default action is Open).

  • When the file selection dialog box is used to choose an existing directory or to specify a new directory or file, the files list should not appear.

Required 

7-13: 

The normal text navigation and editing functions are available in the text components for moving the cursor within each text component and changing the contents of the text. 

These actions provide a convenient way to choose a directory or file name from the corresponding List while focus remains in the Text component. 

Optional 

7-15 

Your application allows the user to select a file by scrolling through the list of file names and selecting the desired file or by entering the file name directly into the file selection text component. Selecting a file from the list causes that file name to appear in the file selection text area. 

This method for selecting a file needs to be consistent across applications. 

Required 

7-16 

Your application makes use of the selection when one of the following occurs: 

  • The user activates the command push button while an appropriate item is selected in the contents List.

  • The user double-clicks BSelect on an appropriate file in the contents list.

  • The user presses Return or Enter while the file name text component has the keyboard focus and contains an appropriate item.

Guidelines for Specific File Selection Dialog Box Uses

The following guidelines apply for specific uses of the file selection dialog box, and should be observed in addition to the more general guidelines.

Open Dialog

Recommended 

hm: 

If the user has opened the application without supplying a file name argument, the Open dialog box should use the user's home directory as the default directory. 

An exception to this rule might be made if a clearly more useful directory can be identified; for example, the icon editor might default to $HOME/.dt/icons. For applications that allow editing, never default to a directory in which the user does not have read and write permission, such as /usr/dt/bin. 

Required 

hn: 

If the user has opened the application with a file name argument, the Open dialog box should default to the directory in which that file resides. 

Save As Dialog

Optional 

ho: 

When using the file selection dialog box in Save As capacity, provide a default name of Untitled, place the location cursor in the file name field and highlight the file name text to create a "delete pending type-in" mode. If the current directory already has a file of that name, create a name Untitled2, and so forth. 

Optional 

hp: 

When using the file selection dialog box in a Save As capacity, add a file name extension if the application supports file typing by extension, and make this extension visible in the file name field. Do not highlight the extension to create a "delete pending type-in" mode, but allow users to modify the extension or delete it explicitly. 

After saving a file using "Save As", the application should use that newly saved file as the current file, and all subsequent edits and saves should apply to that newly created file. 

The Save As dialog should use the same directory in which the current file resides.  

Directory Selection Dialog

Recommended 

hh: 

When the file selection dialog box is used to choose an existing directory (for example, to install a set of files into the chosen directory) or to specify a new directory, the command button should be given an appropriate label, such as Install, Choose, Create, or OK. If this button is activated while the appropriate directory is selected in the contents list, the directory is utilized by the application and the file selection box is dismissed. 

Required 

hi: 

When the file selection dialog box is used to choose an existing directory, there must also be an additional button, labeled Update, that is enabled whenever a directory is selected in the contents list, and opens the directory. This Update button is the default action. 

Optional 

hk: 

When the file selection dialog box is used to choose an existing file, files are shown in the contents list but they are all disabled. Double-clicking BSelect on a disabled file name has no effect. 

Print Dialog Box

These are guidelines for a common look and feel print dialog box, which may be used wherever a print action is available. The print dialog is not a widget. Developers are encouraged to use these guidelines as a starting point and to add functionality as appropriate for their applications. It is important, however, to remember that users expect consistency from one print dialog to another; therefore, the common area should be left as unchanged as possible. Use a print dialog box whenever users would want to select options for printing a file, a selection, or other type of object. If your application supports printing, you should use a print dialog box, and you may provide an optional nondialog method of printing directly, that is, "silent" printing.

Standard Print Menu Items for Applications

Print...: brings up a print dialog so the user can choose from the available options before printing the selected objects.

Print One: prints one copy of the selected objects, using the default print methods previously defined by the user. The user is not prompted for further information through a dialog.

Guidelines for Common Print Dialog Functions

Applications are expected to provide many different types of printing functions and capabilities. This section provides guidelines for the most commonly used types of print options so that appearance and behavior for these items is consistent across applications. These common items are grouped into a common area that is located in the top portion of the print dialog. Figure 7-5 shows a typical print dialog. The common area is the area above the separator line.

Figure 7-5 A basic print dialog. box

Graphic

The common area contains the following components:

Guidelines for Application-Specific Print Dialog Box Functions

The standard print dialog application-specific area is the bottom half of the dialog box illustrated in Figure 7-6.

Depending upon the application or function, developers may choose to add more fields to the common Print dialog. The controls in the dialog are laid out horizontally; if more fields are needed, it is suggested that you add another separator line, then place the additional controls below it, as illustrated. If any additional push buttons are needed, they should go between the Print and Cancel buttons.

Optional Fields

Some possible optional fields include:

Print Page Numbers

This checkbox applies only when ASCII files are being printed. If the objects selected for printing are non-ASCII, this control should be dimmed. When turned on, output pages will be numbered.

Print Command Options

A text field where the user may type an lp command or script name to override the instructions in the other fields. If you want to provide print methods besides lp, rename this field (Print Method, Use Print Command, and so on).

Priority

This might be an option menu containing values for High, Medium, and Low, or might be a spin box containing numbers.

Orientation

An option menu containing the values Portrait and Landscape (see Figure 7-6).

Resolution

An option menu or a spin box containing numeric values, in dpi (see Figure 7-6).

Sides

An option menu containing the values Single and Double (see Figure 7-6).

Paper Size

An option menu containing the values Letter, Legal, and so on. (Figure 7-6).

Paper Source

An option menu containing the values Upper Tray, Lower Tray, and so on. (see Figure 7-6).

If the dialog box is to be used for an application, consider:

Page Range

Two text fields, from x to y (see Figure 7-7).

Reduce/Enlarge

A spin box containing values for percentages (see Figure 7-7).

Print Preview

A button that brings up a WYSIWYG representation of the output.

Some Sample Layouts

Figure 7-6 and Figure 7-7 show some example Print dialog box layouts.

Figure 7-6 Example print dialog box layout for general printing

Graphic

Figure 7-7 Example print dialog box layout for printing from applications

Graphic

The Properties Dialog

User a properties dialog if your application provides settings that control the behavior of an application or the characteristics of an object.

Guidelines

Recommended 

cz: 

If your application manages objects and allows the user to see or modify settings for these objects, these settings are displayed in an object properties window that is accessible from a Properties ... choice in the Edit, <object-type>, or Selected menus, as well as from the pop-up menu associated with the object. 

Recommended 

da: 

If your application provides access to a Properties or Options window, this window includes the following set of buttons in the order listed, with the specified functionality, when supported by your application. 

 

 

OK 

Applies any changes made to components in the DialogBox and dismisses it. OK may be replaced by a more appropriate label (for example, Add). The alternate label should be a verb phrase. 

 

 

Apply 

Applies any changes made to components in the DialogBox and does not dismiss it. 

 

 

Reset 

Cancels any changes that have not yet been applied by your application. The controls within the DialogBox are reset to their state since the last time the DialogBox action was applied. If no changes have been applied within the current invocation of the DialogBox, the controls are reset to their state as of when the DialogBox was first displayed. 

 

 

Reset to Factory 

Cancels any changes that have not yet been applied. Components in the dialog box are reset to their default state or value as specified by the vendor that delivered the application (that is, the controls are restored to the original factory settings). 

 

 

Cancel 

Dismisses the dialog box without performing any actions not yet applied. 

 

 

Help 

Provides help for the dialog box. 

Recommended 

db: 

If your application provides a Properties window that displays settings for a selected object, the Properties window tracks the current selection and modifies the state of any controls to accurately reflect the properties of the currently selected object. 

The About Dialog Box

The About dialog box is used to present version and other information about your application. Use as the dialog that comes up when the user chooses About <application name> from the Help menu.

Guidelines for the About Dialog Box

The About dialog box should contain a minimum set of information about the application that is visible in a single text pane.

That minimum set should be:

Required 

di: 

The About dialog box should contain a Close button. Other buttons are optional, such as Help and More. 

The following information might also be contained in the About box:

Recommended 

dj: 

Information about the operating system or other aspects required to run the application, for example, Common Desktop Environment 1.0. 

Optional 

dk: 

A More Information dialog box for additional information such as development team credits, licensing, client or xhost information. 

Figure 7-8 Example About dialog box

Graphic

Figure 7-9 About dialog box with a More button

Graphic