Dialogs and Forms

This article will describe the characteristics of modal dialogs, modeless dialogs and forms. And give some guide lines for when and how to use each kind.

Characteristics

Forms

• Appear in the Window menu
• Can be hidden below other windows
• React to Ctrl-TAB and Ctrl-Shift-TAB
• Can (normally) be cascaded and tiled

Dialogs

• Don't appear in the Window menu
• Stay on top of other windows
• Don't react to Ctrl-TAB and Ctrl-Shift-TAB
• Don't take part in cascading and tiling

Modal Dialogs

• Block the rest of the application. Subsequently, if a modal dialog is active in an application, then it is the only thing that is active in the application (i.e. for user input)
• In the program the control is not returned until the dialog is closed. So the "result" of the modal dialog is available when control returns.

Modeless Dialog (and Forms)

• Does not block the application, so several modeless dialogs and forms can be active simultaneously, and simultaneous with the menu, toolbars, minimize, maximize, etc of the application.
• In the program the control returns as soon as the modeless dialog/form has been created/shown. So the "result" is not awailable when the control returns from the creation/display call.

Guidelines

Forms should be used for "documents" and "data" and dialogs should be for "questions to"/"conversations" with the user.

Dialogs should normally have:

• an OK button, which terminates the "conversation" in a confirmative fashion, and
• a Cancel button, which terminates the "conversation" in a rejecting/regretting fashion

Since these buttons terminates the "conversation" the dialog will also close. By default the escape button will cancel the dialog.

Forms which represents a more stationary view should normally not have neither "OK" or "Cancel" buttons since they are not considered part of a "conversation". Forms are normally closed using the the cross in the upper-right corner or by using Ctrl-F4.

Both forms and dialogs can have other buttons, which performs "actions"/"commands". Such buttons should only close the form/dialog if the action really requires/indicate this.

Forms and modeless dialogs should be independent "top level" entities, they can have effect on each other, but they should be "on same level". They should never expect that some other form/dialog is present, etc. As such they should have the applicationWindow as parent.

Modal dialogs may seem appealing from a programming point of view, because the flow of the program can be written as a sequence of actions:

• Ask about the users name
• Greet the user and ask about a color
• Say "Thank you" in the chosen color

But this approach has many drawbacks:

1. It restricts the users possibilities quite a lot: There is only one path through the sequece. It is of course possible to put "if's" and the like into the sequence. But that approach will very soon result in an untractable complexity, which is far more difficult to program than the "professional" choice.
2. It is a very good idea to make sure that the "action" of the dialog to be carried out while the dialog is still active, because if something is not quite right the user will prefer that the entered data remains in the dialog for a second (or third ...) attempt.
3. While active modal dialogs block the entire application (i.e. except for the dialog itself). This is very unpleasent for users and should therefore be reserved for "high-attention/critical" questions/notifications. Notice that you cannot even minimize an application while a modal dialog is active.

There are other reasons, but these are the most important ones and they are certainly sufficient to seek other means.

The other means is to perform the "action(s)" inside the dialog/form.

The example Dialogs and Forms: Modeless dialogs example illustratres how to jump from one modeless dialog to another as a "final" action. (The same approach is possible for forms). It is worth noticing that "Cancel" is handled without any checks for OK/Cancel at all. One of the forms has three different "final actions", in the example they do practically the same thing but they could just as well have done something different. Again there is no need for elaborative testing because the actions are tied to the buttons rather than handled as a "result" of the dialog.