Core Java Books

Thursday, 10 March 2011

JInternalFrame's Parent & Child Modality

This post is about managing JInternalFrame's within a JDesktopPane, specifically the ability to popup child JInternalFrame's from a parent JInternalFrame's. Now why would you want to do this you may ask? Well on several applications I have worked on users open forms to view/enter data, these forms then offer extra buttons to view related data in other forms. In many cases I require that the new form blocks the parent form, in short becomes modal to the parent form (not other forms).

This post offers code and a demo of a simple extension to JInternalFrame which controls the child and parent relationship. It also offers non desktop modal dialogs, but dialogs that are only modal to the parent JInternalFrame.

The functionality the provided specifically is:

  1. Frames can open child frames. The parent frame becomes busied out (lightweight modal).
  2. Clicking on a busied out parent frame brings the top related child frame to the front.
  3. Multiple parent and child hierarchy's can be on the desktop at one time.
  4. A frame can open a dialog, the dialog can be either desktop modal or modal just to the frame hierarchy it was opened from.
  5. A frame modal dialog will be brought to the front if any of its parent frames are clicked on.
Please try out the demo, the list below gives some idea of the functionality.

Play around with the demo, the menu lets you open many frames that are not related. Each frame then has buttons to let you open different children. Notice how you can click on different children and children of children and also busied out parents, you will see that the top most child frame of the associated from clicked is always brought to the front, even if iconized.

I think many people will find this functionality useful in JDesktopPane related applications

Try it out:

You can download the code from here have a look and figure it out.

Basically I have overridden JInternalFrame and added functionality to listen out for child frames opening and closing. This caused glassplanes to be installed or removed as appropriate.  Check out the logic, its easy(ish) to follow. Let me know if you can think of other uses or extensions to this.

In future I will create a post to demonstrate full modality for internal frames ;)

UPDATE: AUG 2016 - Google have retired the Google Drive Archive :( If you wish to obtain the code please email me and I can send it via email or you can obtain the whole archive here.

Please give a recommend below if you liked the article.


  1. Excellent work. Thanks!

  2. Great, that is just what i was looking for.
    Thanks a lot.

  3. Hi Steve. Very helpful so far, but I've noticed that if the parent has the closable attribute set to true, when the child is closed, it did not set back the closable to the parent frame. I've added to my code cause it's important for me that behavior. Thanks..
    Ulises Estecche (

    1. I also was looking for that. There are other solutions being way more complicated in implementation. Excellent work.
      I agree with Ulises. It seems you forgot a little line for the correct closeable handling in a parent after the child was closed:

      protected void childOpening()
      // record the present focused component
      !!! wasCloseable = isClosable(); !!!
      this.setClosable(false) ;

      Anyway... Thanxs from here

    2. It's taken a while to reply ;)

      Yes you are correct that change is needed. Interestingly it wasn't required when I tested the code with the latest version of Java when it was written so obviously something in the JDK was changed which now means it is required.

  4. Thank you so much.. I was digging the forums for weeks to get this code.. Itz really helpful.. Thanks a lot. I have been using JDialogs before.. But i missed one feature. ModalityInternalFrame cannot return a value.. Any way thanks

  5. Hi
    Thanks for this class.
    I have a problem with "ModalityInternalFrame".
    When I create/Show it from "actionPerformed" event of a "JMenuItem" it uses 100% of CPU when it is visible! (But showing from actionPerformed" event of a "JButton" has no problem!!)
    What is the problem?

    1. Well it really shouldn't make any difference where the event is driven from because it's all on the event thread. Maybe you haven't set the parent parameter correct when opening from the a menu item.

      Alternatively maybe it is the version of Java you are using. Since this demo was written the code in the JDK may have been restructured but I doubt it.

      I'm now working on GWT and GXT projects so I haven't used swing for more than 12 months now.

    2. now ,I checked it with other Look and Feels and I found that this only occurs with Nimbus!! other Look And Feels (Metal & GTK tested) are OK! Can It be a Nimbus Bug?
      I'm using JDK 1.6.0_14

  6. thanks!!! i was looking for this!!.

    1. Great glad it was useful to you Steve. Sorry for the long delay in answering, I almost forgot about this blog!

  7. Thank you a lot!

    1. No problem Daniel I'm glad some of the stuff on my old blog is still useful. I haven't been working on Swing for a while now as I'm doing web based work but it would be nice to take a look at Swing and JavaFX again at some point.

  8. Hi, Im using it and its awesome, thanks.

    I do have one question, Im trying to add a ProgressBar for lengthy operations, but Im not able to disable the parent window from which the lengthy operation is called, caan ou help me please

  9. Hi Steve,
    Thanks a lot for this, Awesome!!

  10. This classes are very helpful. Thanks a lot.