A lightweight container used behind the scenes by
JInternalFrame.
For task-oriented information on functionality provided by root panes
see How to Use Root Panes,
a section in The Java Tutorial.

The following image shows the relationships between
the classes that use root panes.

The lightweight container
JInternalPane is shown.
JFC/Swing containers implement the
RootPaneContainer interface,
and they all delegate their operations to a
JRootPane (shown with a little "handle" on top).

Note: The JComponent method getRootPane
can be used to obtain the JRootPane that contains
a given component.

The diagram at right shows the structure of a JRootPane.
A JRootpane is made up of a glassPane,
an optional menuBar, and a contentPane.
(The JLayeredPane manages the menuBar
and the contentPane.)
The glassPane sits over the top of everything,
where it is in a position to intercept mouse movements.
Since the glassPane (like the contentPane)
can be an arbitrary component, it is also possible to set up the
glassPane for drawing. Lines and images on the
glassPane can then range
over the frames underneath without being limited by their boundaries.

Although the menuBar component is optional,
the layeredPane, contentPane,
and glassPane always exist.
Attempting to set them to null generates an exception.

To add components to the JRootPane (other than the
optional menu bar), you add the object to the contentPane
of the JRootPane, like this:

rootPane.getContentPane().add(child);

The same principle holds true for setting layout managers, removing
components, listing children, etc. All these methods are invoked on
the contentPane instead of on the JRootPane.

Note: The default layout manager for the contentPane is
a BorderLayout manager. However, the JRootPane
uses a custom LayoutManager.
So, when you want to change the layout manager for the components you added
to a JRootPane, be sure to use code like this:

rootPane.getContentPane().setLayout(new BoxLayout());

If a JMenuBar component is set on the JRootPane,
it is positioned along the upper edge of the frame.
The contentPane is adjusted in location and size to
fill the remaining area.
(The JMenuBar and the contentPane are added to the
layeredPane component at the
JLayeredPane.FRAME_CONTENT_LAYER layer.)

The layeredPane is the parent of all children in the
JRootPane -- both as the direct parent of the menu and
the grandparent of all components added to the contentPane.
It is an instance of JLayeredPane,
which provides the ability to add components at several layers.
This capability is very useful when working with menu popups,
dialog boxes, and dragging -- situations in which you need to place
a component on top of all other components in the pane.

The glassPane sits on top of all other components in the
JRootPane.
That provides a convenient place to draw above all other components,
and makes it possible to intercept mouse events,
which is useful both for dragging and for drawing.
Developers can use setVisible on the glassPane
to control when the glassPane displays over the other children.
By default the glassPane is not visible.

The custom LayoutManager used by JRootPane
ensures that:

The glassPane fills the entire viewable
area of the JRootPane (bounds - insets).

The layeredPane fills the entire viewable area of the
JRootPane. (bounds - insets)

The menuBar is positioned at the upper edge of the
layeredPane.

The contentPane fills the entire viewable area,
minus the menuBar, if present.

Any other views in the JRootPane view hierarchy are ignored.

If you replace the LayoutManager of the JRootPane,
you are responsible for managing all of these views.
So ordinarily you will want to be sure that you
change the layout manager for the contentPane rather than
for the JRootPane itself!

The painting architecture of Swing requires an opaque
JComponent
to exist in the containment hieararchy above all other components. This is
typically provided by way of the content pane. If you replace the content
pane, it is recommended that you make the content pane opaque
by way of setOpaque(true). Additionally, if the content pane
overrides paintComponent, it
will need to completely fill in the background in an opaque color in
paintComponent.

Warning:
Serialized objects of this class will not be compatible with
future Swing releases. The current serialization support is
appropriate for short term storage or RMI between applications running
the same version of Swing. As of 1.4, support for long term storage
of all JavaBeansTM
has been added to the java.beans package.
Please see java.beans.XMLEncoder.

paint

Invoked by Swing to draw components.
Applications should not invoke paint directly,
but should instead use the repaint method to
schedule the component for redrawing.

This method actually delegates the work of painting to three
protected methods: paintComponent,
paintBorder,
and paintChildren. They're called in the order
listed to ensure that children appear on top of component itself.
Generally speaking, the component and its children should not
paint in the insets area allocated to the border. Subclasses can
just override this method, as always.

getJMenuBar

setContentPane

public void setContentPane(java.awt.Container content)

Sets the content pane -- the container that holds the components
parented by the root pane.

Swing's painting architecture requires an opaque JComponent
in the containment hiearchy. This is typically provided by the
content pane. If you replace the content pane it is recommended you
replace it with an opaque JComponent.

getLayeredPane

Gets the layered pane used by the root pane. The layered pane
typically holds a content pane and an optional JMenuBar.

Returns:

the JLayeredPane currently in use

setGlassPane

public void setGlassPane(java.awt.Component glass)

Sets a specified Component to be the glass pane for this
root pane. The glass pane should normally be a lightweight,
transparent component, because it will be made visible when
ever the root pane needs to grab input events. For example,
only one JInternalFrame is ever active when using a
DefaultDesktop, and any inactive JInternalFrames'
glass panes are made visible so that clicking anywhere within
an inactive JInternalFrame can activate it.

getGlassPane

isValidateRoot

public boolean isValidateRoot()

If a descendant of this JRootPane calls
revalidate, validate from here on down.

Deferred requests to layout a component and its descendents again.
For example, calls to revalidate, are pushed upwards to
either a JRootPane or a JScrollPane
because both classes override isValidateRoot to return true.

isOptimizedDrawingEnabled

public boolean isOptimizedDrawingEnabled()

The glassPane and contentPane
have the same bounds, which means JRootPane
does not tiles its children and this should return false.
On the other hand, the glassPane
is normally not visible, and so this can return true if the
glassPane isn't visible. Therefore, the
return value here depends upon the visiblity of the
glassPane.

setDefaultButton

Sets the defaultButton property,
which determines the current default button for this JRootPane.
The default button is the button which will be activated
when a UI-defined activation event (typically the Enter key)
occurs in the root pane regardless of whether or not the button
has keyboard focus (unless there is another component within
the root pane which consumes the activation event,
such as a JTextPane).
For default activation to work, the button must be an enabled
descendent of the root pane when activation occurs.
To remove a default button from this root pane, set this
property to null.

addImpl

Overridden to enforce the position of the glass component as
the zero child.

Parameters:

comp - the component to be enhanced

constraints - the constraints to be respected

index - the index

paramString

protected java.lang.String paramString()

Returns a string representation of this JRootPane.
This method is intended to be used only for debugging purposes,
and the content and format of the returned string may vary between
implementations. The returned string may be empty but may not
be null.

paintComponent

Calls the UI delegate's paint method, if the UI delegate
is non-null. We pass the delegate a copy of the
Graphics object to protect the rest of the
paint code from irrevocable changes
(for example, Graphics.translate).

A script enabled browser is required for this page to function properly.A script enabled browser is required for this page to function properly.A script enabled browser is required for this page to function properly.A script enabled browser is required for this page to function properly.A script enabled browser is required for this page to function properly.