handle to a dialog, and if you need to conserve memory and other resources, you should destroy the dialog whenever
you pop it down.
Another method the user might use to close a dialog is to select the Close item from the window menu. This menu can
be pulled down from the title bar of a window. Since the menu belongs to the window manager, rather than the shell
widget or the application, you cannot install any callback routines for its menu items. However, you can use the
XmNdeleteResponse resource to control how the DialogShell responds to a Close action. The Motif VendorShell,
from which the DialogShell is subclassed, is responsible for trapping the notification and determining what to do next,
based on the value of the resource. It can have one of the following values:
XmUNMAP
This value causes the dialog to be unmapped. The dialog disappears from the screen, but it is not destroyed,
nor is it iconified. The dialog widget and its windows are still intact and can be redisplayed using
XtPopup(). This value is the default for DialogShells.
XmDESTROY
This value destroys the DialogShell and calls its XmNdestroyCallback. Note that all of the shell's
children are also destroyed, including the dialog widget and its subwidgets. When the dialog is destroyed, you
cannot redisplay the dialog or reference its handle again. If you need the dialog again, you have to create
another one. Examples of using the XmNdestroyCallback are presented in Chapter 21, Advanced Dialog
Programming.
XmDO_NOTHING
This value causes the toolkit to take no action. The value should only be specified in circumstances where you
want to handle the event on your own. However, handling the event involves much more than installing a
simple callback routine. It requires building a lower−level mechanism that interprets the proper events when
they are sent by the window manager. The most common thing to do in such cases is to activate the default
action of the dialog or to interpose a prompting mechanism to verify the user's action. This topic is discussed
in Chapter 16, Interacting With the Window Manager.
It may be convenient for your application to know when a dialog has been popped up or down. If so, you can
install callbacks that are invoked whenever either of these events take place. The actions of popping up and
down dialogs can be monitored through the -XmNpopupCallback and XmNpopdownCallback callback
routines. For example, when the function associated with a XmNpopupCallback is invoked, you could
position the dialog automatically, rather than allowing the window manager to control the placement. See
Chapter 7, Custom Dialogs, for more information on these callbacks.
6.3.6 Generalizing Dialog Creation
Posting dialogs that display informative messages is something just about every application is going to do frequently.
Rather than write a separate routine for each case where a message needs to be displayed, we can generalize the
process by writing a single routine that handles most, if not all, cases. the source code shows the PostDialog()
routine. This routine creates a MessageDialog of a given type and displays an arbitrary message. Rather than use the
convenience functions provided by Motif for each of the MessageDialog types, the routine uses the generic function
XmCreateMessageDialog() and configures the symbol to be displayed by setting the XmNdialogType
resource. XmStringCreateLocalized() is only available in Motif 1.2; XmStringCreateSimple() is the
corresponding function in Motif 1.1.
/*
* PostDialog() −− a generalized routine that allows the programmer
* to specify a dialog type (message, information, error, help, etc..),
6 Introduction to Dialogs 6.3.6 Generalizing Dialog Creation
119

Get Volume 6A: Motif Programming Manual now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.