GEOS SDK TechDocs
|
| 
4.2 Dismissing Interactions
| 
4.4 Managing Input
MSG_GEN_INTERACTION_TEST_INPUT_RESTRICTABILITY
By default, GIV_DIALOG GenInteractions appear as non-modal windows. You may specify a dialog Interaction to appear as modal by setting either the GIA_MODAL attribute in the
GII_attrs
instance data field or by adding
HINT_INTERACTION_MODAL
in the object's vardata. When a modal dialog is displayed, input to all other parts of the application will be ignored until the dialog is dismissed. In OSF/Motif, modal dialogs will appear with thick borders.
You should use GIA_MODAL dialogs when the application depends on an Interaction being modal to operate correctly. For example, if a dialog shows information about the current selection but the application cannot update that information if the user were to change the current selection, you should use a GIA_MODAL dialog.
You should use
HINT_INTERACTION_MODAL
dialogs for cases where the modality of a dialog simplifies the interface between the application and the user but is not needed for the application's correct operation. The Interaction's modality in this case will make the UI clearer and simpler for the user to understand. For example, a dialog for setting obscure options that is brought up from a command dialog might be marked HINT_INTERACTION_MODAL so that the user is forced to set the options before returning to the command dialog. This will prevent the user from using this dialog box in a context where the options are not self-evident. As with all hints, the Specific UI may decide to ignore the hint and implement a HINT_INTERACTION_MODAL dialog with a non-modal dialog.
You may also initiate a modal dialog with
UserDoDialog()
. Such a dialog must have both the GIA_INITIATED_VIA_USER_DO_DIALOG and GIA_MODAL attributes set. Using this routine not only blocks input to other parts of the application but blocks the calling thread's execution until the dialog is dismissed.
UserDoDialog()
is useful for displaying notifications where the user's response is required before the application's thread may continue. For more information, see Thread Blocking Routines
.
Dialogs displayed with
UserStandardDialog()
and
UserStandardDialogOptr()
are also modal. Both will block the calling thread until the dialog is dismissed. (See Thread Blocking Routines
.)
Some modal dialogs will have subcomponents such as pop-up lists that must be interactable while the dialog is modal. The GenApplication object running the modal dialog will query the dialog to test both its input restrictions and its interactability in these cases; it uses two messages, described below.
Boolean MSG_GEN_INTERACTION_TEST_INPUT_RESTRICTABILITY(
optr obj);
This message is called on a modal window by a GenApplication object to find out whether or not the various input restricting mechanisms (input hold-up, input ignore, busy states, etc.) should be overridden or not.
Source: Part of the input flow/modality mechanism--sent by the GenApplication object to the modal window.
Destination: The modal GenInteraction object.
Parameters: obj The optr of the windowed object that may or may not be restricted.
Return: Will return
true
if input restrictions should be overridden, false otherwise. A
true
return value indicates that mouse and keyboard input will flow to the object regardless of hold-up, ignore, or busy states.
Interception: May be intercepted to allow the passed windowed object to override its input restrictions in certain cases.
GEOS SDK TechDocs
|
| 4.2 Dismissing Interactions
| 4.4 Managing Input