Newsletter sign-up
View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Conquer Swing deficiencies in MDI development

Add more functionality to your Multiple Document Interface (MDI) applications

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Developers have used the Multiple Document Interface (MDI) for many years. It provides an understandable interface for building applications that require multiple documents or windows to be hosted simultaneously within a parent application. In an MDI application, a parent application contains a main application frame that hosts a variety of child frames within it. Users can then move, resize, minimize, and maximize these child windows on the desktop as desired.

Creating an MDI application in Swing is relatively trivial. Swing provides two out-of-box components for creating MDI applications: JDesktopPane and JInternalFrame. You use JDesktopPane as the hosting frame while JInternalFrames act as the child frames that users move and resize.

On the surface, Swing seems to provide all the desired behavior for building an MDI application. However, creating an MDI application that behaves like users expect is quite challenging. For one reason or another, Swing's designers have omitted what would be considered standard MDI functionality on other platforms. The two most often requested features appear to be as follows:

  1. Making the desktop pane scrollable: As a user positions some or all of an internal frame outside the desktop pane's viewable area, scrollbars will magically appear. This is required so that a user doesn't accidentally "lose" a child frame by positioning it outside the desktop pane's viewable area.
  2. Having a windows menu available: A windows menu that lists all active child frames and lets users easily switch focus between the child frames is needed as well.


Scroll a desktop pane

The first issue we will tackle is allowing the desktop pane to automatically show scrollbars when a child frame is positioned outside its viewable area. We will create this desired behavior by extending the JDesktopPane class into our own MDIDesktopPane. The standard mechanism for adding scroll capability to a component is to first create the component and then add it to a scroll pane's viewport. One of our design goals should be to preserve this methodology of achieving scrolling in our MDIDesktopPane.

We are going to add scrolling to the desktop pane by simply increasing and decreasing the desktop pane's physical size as needed. Increasing the desktop pane's size beyond the size of the scroll pane's viewport will cause scrollbars to appear automatically. Of course, we have to make sure that the desktop pane isn't sized smaller than the scroll pane's viewport.

To accomplish this, we must be able to track the activity of child frames within the desktop pane. When the user finishes moving a child frame, we must determine if the child frame is now out of the desktop pane's bounds, and if so, increase the desktop pane's size so it encompasses the outer edges of the newly moved child frame. In a nutshell, every time the user adjusts the child frame's size or position, we must check the positioning of all child frames and adjust the desktop pane's size to ensure that it encompasses the outermost edges of the child frames.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comments (1)
Login
Forgot your account info?

Some locking requiredBy Anonymous on May 22, 2009, 1:11 pmI tried using this and have noticed that if a frame gets removed mid resizeDesktop, the Frames[] array can end up pointing to a null frame. So ideally there should...

Reply | Read entire comment

View all comments

Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources