A primary application modal dialog (what a name!) is the fourth - and
last - kind of LESSTIF's dialog types. Whenever such a dialog is
visible, the user can interact with any dialog that is not a
parent of the primary application modal dialog, just as with any other
top level shell. Unfortunately, the behaviour just described isn't
suited to the Xt grab mechanism at all. LESSTIF therefore has to do
some work behind the scenes to get the desired grab behaviour: it must
reissue all grabs that do not belong to any of the parental shells of
our primary application modal dialog. A more elaborate example, figure
, shows the grab list after a primary application
modal dialog popped up.
For some reason - yet not fully understood - M*TIFreissues the grabs for the shells, which aren't parents of the primary application modal dialog, only if mwm is present. Users of other window managers - like the famous fvwm - look (literally spoken) into the tube.
When popping down a primary application modal dialog, LESSTIF must
get rid off all those grabs that once were necessary to get the
desired grab behavior. In figure the two grabs in
the slots #2 and #4 are belonging to the modeless dialog
3. But only the grab from slot #4 must be
removed together with the grab #3 that belongs to the primary
application modal dialog.
This is where the grabber member mentioned above comes in. In the case of a primary application modal dialog the grabber links to an object (of class XmVendorShellExtObject) that belongs to the shell widget of the primary application modal dialog. All we then have to do inside LTRemoveGrab() is to remove all grabs from the list whose grabber belongs to the primary application modal dialog just popped down. In other cases of dialog grabs the member grabber links to the extension object of the same shell as referenced in wid.