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

Forms should be used form "documents" and dialogs for "questions".

Modal Dialogs

• Block the rest of the application. Subsequently, if a modal dialog is active in an application, then it the 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 awailable when control returns.

Modeles 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

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 "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.