Volume 6A: Motif Programming Manual

dialog = XmCreateInformationDialog (parent, "message", args, 1);

XmStringFree (text);

XtSetSensitive (

XmMessageBoxGetChild (dialog, XmDIALOG_HELP_BUTTON), False);

XtUnmanageChild (

XmMessageBoxGetChild (dialog, XmDIALOG_CANCEL_BUTTON));

The output of a program using this code fragment is shown in the figure.

MessageDialog with an unmanaged Cancel button and an insensitive Help button

Since the message in this dialog is so simple, it does not make sense to have both an OK and a Cancel button, so we

unmanage the latter. On the other hand, it does make sense to have a Help button. However, there is currently no help

available, so we make the button unselectable by desensitizing it using XtSetSensitive().

6.7 Dialog Modality

The concept of forcing the user to respond to a dialog is known as modality. Modality governs whether or not the user

can interact with other windows on the desktop while a particular dialog is active. Dialogs are either modal or

modeless. There are three levels of modality: primary application modal, full application modal, and system modal. In

all cases, the user must interact with a modal dialog before control is released and normal input is re-sumed. In a

system modal dialog, the user is prevented from interacting with any other window on the display. Full application

modal dialogs allow the user to interact with any window on the desktop except those that are part of the same

application as the modal window. Primary application modal dialogs allow the user to interact with any other window

on the display except for the window that is acting as the parent for this particular dialog.

For example, if the user selected an action that caused an error dialog to be displayed, the dialog could be primary

application modal, so that the user would have to acknowledge the error before she interacts with the same window

again. This type of modality does not restrict her ability to interact with another window in the same application,

provided that the other window is not the one acting as the parent for the modal dialog.

Modal dialogs are perhaps the most frequently misused feature of a graphical user interface. Programmers who fail to

grasp the concept of event−driven programming and design, whereby the user is in control, often fall into the

convenient escape route that modal dialogs provide. This problem is difficult to detect, let alone cure, because there

are just as many right ways to invoke modal dialogs as there are wrong ways. Modality should be used in moderation,

but it should also be used consistently. Let's examine a common scenario. Note that this example does not necessarily

favor using modal dialogs; it is presented as a reference point for the types of things that people are used to doing in

tty−based programs.

6 Introduction to Dialogs 6.7 Dialog Modality

131

A text editor has a function that allows the user to save its text to a file. In order to save the text, the program needs a

filename. Once it has a filename, the program needs to check that the user has sufficient permission to open or create

the file and it also needs to see if there is already some text in the file. If an error condition occurs, the program needs

to notify the user of the error, ask for a new filename, or get permission to overwrite the file's contents. Whatever the

case, some interaction with the user is necessary in order to proceed. If this were a typical terminal−based application,

the program flow would be similar to that in the following code fragment:

FILE *fp;

char buf[BUFSIZ], file[BUFSIZ];

extern char *index();

printf ("What file would you like to use? ");

if (!(fgets (file, sizeof file, stdin)) || file[0] == 0) {

puts ("Cancelled.");

return;

}

*(index (file, '0)) = 0; /* get rid of newline terminator */

/* "a+" creates file if it doesn't exist */

if (!(fp = fopen (file, "a+"))) {

perror (file);

return;

}

if (ftell (fp) > 0) { /* There's junk in the file already */

printf ("Overwrite contents of %s? ", file);

buf[0] = 0;

if (!(fgets (buf, sizeof buf, stdin)) || buf[0] == 0 ||

buf[0] == 'n' || buf[0] == 'N') {

puts ("Cancelled.");

fclose (fp);

return;

}

}

rewind (fp);

This style of program flow is still possible with a graphical user interface system using modal dialogs. In fact, the

style is frequently used by engineers who are trying to port tty−based applications to Motif. It is also a logical

approach to programming, since it does one task followed by another, asking only for information that it needs when it

needs it.

However, in an event−driven environment, where the user can interact with many different parts of the program

simultaneously, displaying a series of modal dialogs is not the best way to handle input and frequently it's just plain

wrong as a design approach. You must adopt a new paradigm in interface design that conforms to the capabilities of

the window system and meets the expectations of the user. It is essential that you understand the event−driven model

if you want to create well−written, easy−to−use applications.

Window−based applications should be modeled on the behavior of a person filling out a form, such as an employment

application or a medical questionnaire. Under this scenario, you are given a form asking various questions. You take it

to your seat and fill it out however you choose. If it asks for your license number, you can get out your driver's license

and copy down the number. If it asks for your checking account number, you can examine your checkbook for that

information. The order in which you fill out the application is entirely up to you. You are free to examine the entire

form and fill out whatever portions you like, in whatever order you like.

6 Introduction to Dialogs 6.7 Dialog Modality

132