This article presents a Java/Swing component implementation of a feature that is ubiquitous in nearly all desktop applications, particularly Windows applications - an area in the lower right portion of a window (Frame) that can be used to resize the window.

Of course, a window can be re-sized with most desktop managers by dragging the lower-right edge - the additional component simply serves as a visual indicator of the resize capability, and also increases the margin of error for the mouse drag.

Typically this component is placed in a status or message area at the bottom of a window. I demonstrate my solution in the context of a very simple (and barely func-tional) Web browser. I also introduce a technique in which a Frame/JFrame/JInternalFrame can exhibit "continuous layout" behavior as it is resized.

Details
The component is called Frame-Resizer. It subclasses JComponent and has two main jobs that it performs. First, it draws itself and, second, it handles mouse events so that it can both change the mouse cursor (on mouse enter/leave) and resize the window (on mouse press/drag/release). FrameResizer can be used to resize a Frame, JFrame, or JInternalFrame, each of which has a common ancestor of java.awt.Container in the component class hierarchy. So constructors for FrameResizer take a Container argument as follows:

public FrameResizer(Container parent);
public FrameResizer(Container parent, boolean useContinuousLayout);

Rendering
Figure 1 shows the FrameResizer in its typical context, at the lower right edge of a window, as part of a status/message area.

FrameResizer draws itself in the paintComponent() method as shown in Listing 1. There are seven "ribs" that make up the component.

A rib is one of the raised "bumps" in the component visual; it's actually just two 2x2 pixel rectangles drawn in different colors offset slightly from each other. You can see this in the exploded view of the FrameResizer in Figure 2.

Resizing
Much of the interesting FrameResizer code is in the MouseInputListener inner class that the component adds to itself. In the mouseEntered() and mouseExited() methods, the cursor is changed to Cursor.NW_RESIZE_CURSOR and the default Cursor, respectively. In the mousePressed() method (see Listing 2), the mouse location is converted to actual screen coordinates, and the relative location from edge of the window (the Point mouseAdjust) is calculated.

In the mouseDragged() method (see Listing 3), the current mouse position is again converted to absolute screen position, and the new bounds of the parent Container (Frame/InternalFrame) are recalculated based on the original mouse location.

The mouseReleased() method calls mouseDragged() for a final calculation, and then "validates" the parent container. Since FrameResizer supports either an external Frame or a JInternalFrame, the validate() method does the appropriate validation and invokes the repaint() method (see Listing 4). This needs to be done at the end of the AWT EventDispatchThread (thus the use of SwingUtilities.invokeLater()). This method is declared static so it can be re-used for the "continuous layout" functionality (see below).

Continuous Layout
This concept is familiar to Swing developers who use JSplitPane - it's the ability to have internal components validate and repaint as the container is resized (in real time). Unfortunately, when a top-level Java desktop window is resized, this doesn't happen, as the validate/repaint messages are not sent to the underlying Container until resizing (via mouse dragging) is complete. Figure 3 is a capture of our browser window during the mouse drag. You can see how the contents of the window are not "stretched' to fit the bounds of the Frame - this is done when the mouse is released.

Ideally you want the contents of the window to stretch to the frame bounds during resizing. This capability is evident in most non-Java top-level desktop windows.

The trick to doing this in Java is to use a Timer to periodically check the current bounds of the window (Frame), and if it has changed since the last interval, send the validate/repaint messages to the Frame. You can see how this is done in Listing 5. I coded it as a static method in FrameResizer so this functionality can be used independently of the component.

The code uses a static HashMap (continuousLayoutWindows) so it can be used for multiple windows in a multi-frame application. It lazily initializes this HashMap. In the map it stores the current Container bounds keyed by the Container. If the current bounds are different than what is in the map, the current bounds are saved and the validate and repaint messages are sent to the Container (our static validate() method from before). That's all there is to it. I use 100 milliseconds (hard-coded) as my timer interval - feel free to experiment with this number (or parameterize it).

You can specify whether or not "continuous layout" is used by the FrameResizer in its constructor (the default is true). Note that one drawback to "continuous layout" in this context is the flicker that occurs during the repaint. This is unfortunately unavoidable. Also note that the continuous layout behavior is not required if you are using the FrameResizer in the context of a JInternalFrame.

Summary
In this article I presented a custom Swing component that can be used to help provide a customary look and feel to a Frame or JInternalFrame. I've also introduced the concept of "continuous layout" to top-level Java desktop windows and shown how this can be implemented. The source code for this article can be downloaded from http://jdj.sys-con.com.