AWT Modality Enhancements in Java SE 6 (Mustang)

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 -

  • Why should a modal dialog block all the windows in the application?
  • Wouldn't it be good if the modal dialog just blocks the parent window and not other windows?
  • Wouldn't it be good if the application developer decides (instead of AWT) what windows should be blocked by the dialog that his application brings up?

  • 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 -

  • Your dialog has to block all the windows in your application (except the ones from the dialog's child hierarchy)
  • Your dialog should block your applet and all other applets from the same toolkit
  • Your dialog should block the browser itself
  • You want to use a dialog with highest scope of blocking

  • 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 ->

  • If there are several applets launched in a browser, they can be treated either as separate applications or a single application depending on what browser you use (Check your browser documentation). Application Modal dialogs will block all the windows from the same 'application'
  • This is the default modality type taken if you do not specify anything for your modal dialog

  • Document - Choose this type if -

  • Your dialog has to block only the windows from the same document('document' is determined by the top-nearest window without an owner).
  • Your dialog should have least scope of blocking, next to being modeless

  • 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.

    Modal Exclusion
    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.

    Modal Excluded Window
    Window excluded from App Modality

    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.

    Parent-less Dialogs
    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.

    Are you excited to know more about this feature and it's usage? Please take a look at the technical article on the new Modality feature in Java SE 6 .


    Post a Comment:
    • HTML Syntax: NOT allowed



    « June 2016