Chapter 16. Desktops and Internal Frames

Subpages: 1. JDesktopPane and JInternalFrame 
2. Internalizable/Externalizable frames 
3. Cascading and outline dragging mode 
4. An X windows style desktop environment 
5. A networked multi-user desktop using sockets 

In this Chapter:

•    JDesktopPane and JInternalFrame
•    Internalizable/Externalizable frames
•    Cascading and outline dragging mode
•    An X windows style desktop environment
•    A networked multi-user desktop using sockets

16.1 JDesktopPane and JInternalFrame

16.1.1  JDesktopPane

class javax.swing.JDesktopPane

JDesktopPane is a powerful extension of JLayeredPane built specifically to manage JInternalFrame children. This is Swing's version of a multiple document interface, a feature common to most modern operating system desktops. In the last chapter we created our own MDI from scratch. Both our MDI and the JDesktopPane/JInternalFrame prebuilt MDI are quite powerful. This chapter focuses mostly on the latter, but we will relate the discussion of it to our own often.

16.1.2  JInternalFrame

class javax.swing.JInternalFrame

The purpose of JDesktopPane is to provide a specialized container for JInternalFrames. We can access its contents identically to JLayeredPane. There are several additional convenience methods defined in JDesktopPane for accessing JInternalFrame children (see API docs) and attaching a DesktopManager implementation (see below).

JInternalFrames are very similar to our custom InnerFrames of chapter 15. They can be dragged, resized, iconified, maximized, and closed. JInternalFrame contains a JRootPane as its main container and implements the RootPaneContainer interface. We can access a JInternalFrame's rootPane and its associated glassPane, contentPane, layeredPane, and menuBar the same way we access them in JFrame and in our InnerFrame.

16.1.3  JInternalFrame.JDesktopIcon

class javax.swing.JInternalFrame.JDesktopIcon

This represents a JInternalFrame in its iconified state. We are warned against using this class as it will disappear in future versions of Swing: "This API should NOT BE USED by Swing applications, as it will go away in future versions of Swing as its functionality is moved into JInternalFrame."^API Currently when a JInternalFrame is iconified it is removed from its JDesktopPane and a JDesktopIcon instance is added to represent it. In future versions of Swing JInternalFrame will have JDesktopIcon functionality built into it.

16.1.4 DefaultDesktopManager

class javax.swing.DefaultDesktopManager

This is the concrete default implementation of the DesktopManager interface. An instance of this class is attached to each JDesktopPane if a custom DesktopManager implementation is not specified.

16.1.5  The DesktopManager interface

abstract interface javax.swing.DesktopManager

Each JDesktopPane has a DesktopManager object attached to it whose job it is to manage all operations performed on JInternalFrames within the desktop. DesktopManager methods are automatically called from the associated JDesktopPane when an action is invoked on a JInternalFrame within that desktop. These are usually invoked when the user performs some action on a JInternalFrame with the mouse:

activateFrame(JInternalFrame f)

beginDraggingFrame(JComponent f)

beginResizingFrame(JComponent f, int direction)

closeFrame(JInternalFrame f)

deactivateFrame(JInternalFrame f)

deiconifyFrame(JInternalFrame f)

dragFrame(JComponent f, int newX, int newY)

endDraggingFrame(JComponent f)

endResizingFrame(JComponent f)

iconifyFrame(JInternalFrame f)

maximizeFrame(JInternalFrame f)

minimizeFrame(JInternalFrame f)

openFrame(JIntenerlFrame f)

resizeFrame(JComponent f, int newX, int newY, int newWidth, int newHeight)

setBoundsForFrame(JComponent f, int newX, int newY, int newWidth, int newHeight)

Note that if we want to manually invoke say, iconification, on a JInternalFrame we should do the following:

    myJInternalFrame.getDesktopPane().getDesktopManager().

      iconifyFrame(myJInternalFrame);

We could also directly call setIcon(true) on a JInternalFrame, but we are discouraged from doing so because it is not good practice to bypass the DesktopManager. The reason this is not good practice is that there may be necessary actions defined within the DesktopManager's iconifyFrame() method that would not be invoked. So, in general, all calls to methods of JInternalFrame that have DesktopManager counterparts should be delegated to the DesktopManager.

We have written an animated demo that shows when and how often each DesktopManager method is called. See \Chapter16\4, and execute the DesktopManagerDemo class. Figure 16.1 illustrates.

Figure 16.1   DesktopManager animated demo.

<<file figure16-1.gif>>

16.1.6  The WindowConstnats interface

abstract interface javax.swing.WindowConstants

Refer to chapter 3 for a description of this interface.

To capture the closing of a JInternalFrame and display a confirmation dialog we can construct the following JInternalFrame subclass:

 class ConfirmJInternalFrame extends JInternalFrame

   implements VetoableChangeListener {

    public ConfirmJInternalFrame(String title, boolean resizable,

     boolean closable, boolean maximizable, boolean iconifiable) {

      super(title, resizable, closable, maximizable, iconifiable);

      addVetoableChangeListener(this);

    }

    public void vetoableChange(PropertyChangeEvent pce)

     throws PropertyVetoException {     

      if (pce.getPropertyName().equals(IS_CLOSED_PROPERTY)) {

        boolean changed = ((Boolean) pce.getNewValue()).booleanValue();

        if (changed) {

          int confirm = JOptionPane.showOptionDialog(this,

            "Close " + getTitle() + "?",

            "Close Confirmation",

            JOptionPane.YES_NO_OPTION,

            JOptionPane.QUESTION_MESSAGE,

            null, null, null);

          if (confirm == 0) {

            m_desktop.remove(this);

            m_desktop.repaint();

          }

          else throw new PropertyVetoException("Cancelled",null);

        }

      }

    }

  }

Using this class in place of JInternalFrame will always display a confirmation dialog when the close button is pressed. This code checks to see if the closed property has changed from its previous state. This is a constrained property which we can veto if desired (see chapter 2). Luckily this comes in real handy for working around the DO_NOTHING_ON_CLOSE bug.

If the confirmation dialog is displayed and then cancelled (i.e.either the "NO"button or the close dialog button is pressed) a PropertyVetoException is thrown which vetos the property change and the internal frame will not be closed. Figure 16.2 illustrates.

Figure 16.2   Handling internal frame closing with a close confirmation dialog.

<<file figure16-2.gif>>

16.1.7  The InternalFrameListener interface

abstract interface  javax.swing.event.InternalFrameListener

Each JInternalFrame can  have one or more InternalFrameListeners attached. An InternalFrameListener will receive InternalFrameEvents allowing us to capture and handle them however we like with the following methods:

internalFrameActivated(InternalFrameEvent e)

internalFrameClosed(InternalFrameEvent e)

internalFrameClosing(InternalFrameEvent e)

internalFrameDeactivated(InternalFrameEvent e)

internalFrameDeiconified(InternalFrameEvent e)

internalFrameIconified(InternalFrameEvent e)

internalFrameOpened(InternalFrameEvent e)

InternalFrameListener and DesktopManager both exist to process changes in a JInternalFrame's state. However, they can both be used to achieve different ends. DesktopManager allows us to define internal frame handling methods for all JInternalFrames within a given JDesktopPane, whereas InternalFrameListener allows us to define InternalFrameEvent handling unique to each individual JInternalFrame. We can attach a different InternalFrameListener implementation to each instance of JInternalFrame, whereas only one DesktopManager implementation can be attached to any  instance of JDesktopPane (and thus, each of its children).

We have written an animated demo that shows when and how often each InternalFrameListener method is called. See \Chapter16\5, and execute the InternalFrameListenerDemo class. Figure 16.3 illustrates.

Figure 16.3   InternalFrameListener animated demo.

<<file figure16-3.gif>>

16.1.8  InternalFrameEvent

 class javax.swing.event.InternalFrameEvent

InternalFrameEvents are sent to InternalFrameListeners whenever a JInternalFrame is activated, closed, about to close, deactivated, deiconified, iconified, and opened. The following static int IDs designate which type of action an InternalFrameEvent corresponds to:

INTERNAL_FRAME_ACTIVATED

INTERNAL_FRAME_CLOSED

INTERNAL_FRAME_CLOSING

INTERNAL_FRAME_DEACTIVATED

INTERNAL_FRAME_DEICONIFIED

INTERNAL_FRAME_ICONIFIED

INTERNAL_FRAME_OPENED

InternalFrameEvent extends AWTEvent, and thus encapsultes its source and the associated event ID  (retrievable with getSource() and getID() respectively).

16.1.9  InternalFrameAdapter

class javax.swing.event.InternalFrameAdapter

This is a concrete implementation of the InternalFrameListener interface. It is intended to be extended for use by InternalFrameListener implementations that need to define only a subset of the InternalFrameListener methods. All methods defined within this adapter class have empty bodies.

16.1.10            Outline dragging mode

JDesktopPane supports an outline dragging mode to help with JInternalFrame dragging performance bottlenecks. To enable this mode on any JDesktopPane we must set the JDesktopPane.dragMode client property:

    myDesktopPane.putClientProperty(

      "JDesktopPane.dragMode","outline");

Instead of actually moving and painting the frame whenever it is dragged, an XOR'd rectangle is drawn in its place until the drag ends. The example in the next section shows outline dragging mode in action.