AWT Modality Enhancements in Java SE 6 (Mustang)
By mohanpraveen on Mar 01, 2006
Modality is always one of my favorite topics just for the fact that lot of interesting customer feedbacks flow in frequently. As a test engineer for Java SE, that's what I am looking for since it keeps me busy and makes my job interesting. On the other hand, this also indicates that modality is one of the widely used features in the client side, be it swing or AWT.
On Java SE 6 (code named Mustang), my work became even more interesting with lots of enhancements being made in the modality land. These enhancements provide lot more flexibity to the application developer in designing the behavior of the modal dialog that his application may bring up. Before getting into the enhancements, let us first see what AWT was offering prior to Mustang.
From it's introduction AWT has only offered two types of modality - Modal and Modeless.
Modal -> Any time a modal window was displayed, all windows in the application would be blocked. Modeless -> A dialog that will not block any of the windows.
It would be interesting to think through certain facts here -
Say if an application user wants to scroll through the help window to see what selections he/she could make in the dialog, when a modal dialog is active, how could he do that?
AWT has addressed this on Java SE 6 , which is now offering 4 types of modality in the order of larger to narrow scope - Toolkit, Application, Document and Modeless. Choose the right modality type for your dialog depending on your needs.
Toolkit - Choose this type if -
Application - There is not much difference between Application and Toolkit modality as far as normal applications are concerned. But if you are developing an applet, then it is important to know the difference. Here you go ->
Document - Choose this type if -
Modeless - Go for it if you don't want your dialog to block any of the windows
(Since Toolkit modal dialogs can block the browser / Java WebStart, you require an AWTPermission 'toolkitModality' to use this type of modality from within an applet)
Overall, this provides lots of flexibility to the application developer in choosing the right modality type for each dialog depending on the extent to which it should block the other top-level windows in the application.
There is another scenario where you have many windows in your application and you want your modal dialog to block all the windows except one. In such a case, you will have to choose the modality type that has the largest scope of blocking but would it be possible to exclude those windows that should not be blocked, from being blocked by the dialog? - YES Indeed!!
Let's see what AWT offers in this area -
AWT has introduced 2 modal exclusion types in Java SE 6 .
Exclusion from blocking of toolkit-modal dialogs
If a window is toolkit-modal excluded, it is not blocked by any application- or toolkit-modal dialogs. Also, it is not blocked by document-modal dialogs from outside of it's child hierarchy (Note: If you are within an applet environment, you would require the AWTPermission - 'toolkitModality' to use this exclusion type).
Exclusion from blocking of application-modal dialogs
If a window is application-modal excluded, it is not blocked by any application-modal dialogs. Also, it is not blocked by document-modal dialogs from outside of its child hierarchy.
By default, a window's modal exclusion property is turned off in the sense that it gets blocked by default if it falls within the scope of blocking of any of the modal dialog that is made visible.
Before using any of the Modality or Exclusion types, check whether it is supported by your platform by calling the methods isModalitySupported(), isModalExclusionTypeSupported() provided in the java.awt.Toolkit class.
Historically, dialogs always have a parent associated with it. But is it really necessary that a dialog should always have a parent? - Not Anymore!!
Now it is possible to create an AWT dialog with a null parent on Java SE 6 by passing a 'null' in the dialog constructor for the 'parent' value. In previous releases, this used to throw an exception.
So if you don't want a parent for your dialog, you don't have to create a dummy one any more!! Doesn't it sound cool?
In addition to this, there are some interesting facts that are worth mentioning -
If the parent-less dialog is document-modal:
A document-modal dialog without an owner would automatically become a root of the document and hence its scope of blocking is empty. So it behaves just like a modeless dialog.
If the parent-less dialog is application or toolkit modal:
The scope of blocking for an application or toolkit-modal dialog (as opposed to a document-modal dialog) doesn't depend on its owner and hence there will be no impact on the scope of blocking.
In any case, a modal dialog should always stay on top of the other top-level windows that it blocks. You can not change the modality type of an already visible dialog. If you do so, you need to hide it and show again so that the new modality type specified comes into effect.