Welcome!

Java Authors: Liz McMillan, Frank Huerta, Elizabeth White, Pat Romanski, Sandi Mappic

Related Topics: Java

Java: Article

FrameResizer

Resizing windows

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.

More Stories By Phil Herold

Phil Herold is VP and CTO of PocketScience LLC in Research Triangle Park, NC. He has over 24 years of experience in software engineering, and has been working with Java client technologies since 1996.

Comments (4) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Phil Herold 09/28/05 10:43:13 AM EDT

The link for the code to this article has been fixed. Here's the direct link:

http://res.sys-con.com/story/aug05/117759/FrameResizer.zip

This contains a jar file with both source and class files. If your run the jar with javaw, it will run the "Lame Browser" window that is shown in the article.

Phil Herold 09/26/05 09:59:47 AM EDT

Michael,

Someone in a private e-mail pointed out that Toolkit.setDynamicLayout() will accomplish the same thing as the timer/validate-paint technique used in my article. I haven't tried it, but you might look at that as well.

Michael Bushe 08/12/05 08:05:03 PM EDT

Brilliant!!! I've been writing fancy Swing apps for a long time and never even considered that there was a way around the gray-screen-as-you-resize problem. Very slick, very thorough. An icon for this was meticulously created by Jonathan Simon here:
http://today.java.net/pub/a/today/2005/06/07/pixelpushing.html

Bill Winspur 08/12/05 06:10:43 PM EDT

Very interesting article - unfortunately I cant find a link to the source code in the article, or on http://jdj.sys-con.com . Can somebody provide it?