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.