1. Full Application Modal Dialogs

With a full application modal dialog on the display, the user must respond to it before she or he can do anything else in the application. To achieve this effect, LESSTIF must block out any user input events which are not meant for the full application modal dialog. LESSTIF therefore issues an exclusive grab on the shell widget of the dialog - see figure . In this figure, as well as in the next few ones, I'll leave out those child widgets of shell widgets that aren't shells themselves - otherwise the figures would be overcrowded.

In addition, in the following figures you'll see some entries on the grab list that are framed by thick edges. These entries form the ``active Xt modal cascade'': user input events are dispatched only to those widgets (as well as to their children) that are part of the active Xt modal cascade. The active Xt modal cascade always starts with the most recent exclusive grab.

Figure: Entries on the grab list after a full application modal dialog popped up.

You may already be wondering why there is another (non-exclusive) grab in slot #1 of the list, just before our exclusive grab for the application modal dialog. This non-exclusive grab belongs to the top level shell of the application. LESSTIF installs such grabs on every VendorShell (or any subclass of) which does not serve as a popup shell (that is, as a dialog). Otherwise the top level shell of an application and any of its children won't receive input anymore as soon as a modeless dialog shows up, because modeless dialogs use grabs, too.