How Layout Management Works - Java Tutorial 5.0 英文版

Start of Tutorial > Start of Trail > Start of Lesson

Search Feedback Form

How Layout Management Works

Here's an example of a layout management sequence for a frame (JFrame).

1. After the GUI is constructed, the pack method is invoked on the JFrame. This specifies that the frame should be at its preferred size.

2. To find the frame's preferred size, the frame's layout manager adds the size of the frame's edges to the preferred size of the component directly contained by the frame. This is the sum of the preferred size of the frame's content pane, plus the size of the frame's menu bar, if any.

3. The content pane's layout manager is responsible for figuring out the content pane's preferred size. By default, this layout manager is a BorderLayout object. However, let's assume that we replace it with a GridLayout object that's set up to create two columns. The interesting thing about grid layout is that it forces all components to be the same size, and it tries to make them as wide as the widest component's preferred width and as high as highest one's preferred height.

   First, the grid layout manager queries the content pane for its insets — the size of the content pane's border, if any. Next, the grid layout manager queries each component in the content pane for its preferred size, noting the largest preferred width and largest preferred height. Then it calculates the content pane's preferred size.

4. When a component in the content pane is asked for its preferred size, the default implementation (used by most components) first checks whether the user specified a preferred size. If so, it reports that size. If not, it queries its look and feel for the preferred size.

The end result is that to determine the best size for the frame, the system determines the sizes of the containers at the bottom of the containment hierarchy. These sizes then percolate up the containment hierarchy, eventually determining the frame's total size.

If you change the size of a component, even indirectly by changing its font, for example, the component automatically resizes and repaints itself. In a custom component, you can force this to occur by invoking revalidate and then repaint on the component. Both revalidate and repaint are thread-safe — you needn't invoke them from the event-dispatching thread.

When you invoke revalidate on a component, a request is passed up the containment hierarchy until it encounters a container, such as a scroll pane or top-level container, that shouldn't be affected by the component's resizing. (This is determined by calling the container's isValidateRoot method.) The container is then laid out, which has the effect of adjusting the revalidated component's size and the size of all affected components.

Start of Tutorial > Start of Trail > Start of Lesson

Search Feedback Form

Copyright 1995-2005 Sun Microsystems, Inc. All rights reserved.