JScrollPane Blunders: Part 2

Our next blunder features a straightforward GUI, shown here:

Nested Scroll 1

The top half of the JSplitPane contains a JScrollPane, which in turn contains a JTable. Tables always need scroll panes, otherwise you won’t see the table headers. The bottom half contains another scroll pane wrapped around a JTextArea.

Dragging the splitter causes the table to scroll, exactly as expected:

Nested Scroll 2

Bring on the Blunder!

The problem is, this screen also uses nested scroll panes. This is a variation of the blunder mentioned in yesterday’s post, where you wrap the entire panel in a big scroll pane.

The difference here is that one or more scroll panes are nested somewhere inside other scroll panes. This never works correctly. Make the screen smaller and you see some really bizarre scrolling:

Nested Scroll 3

And it gets even stranger:

Nested Scroll 4

And sometimes you even get into situations where the screen starts “jittering” and shaking, as scroll bars come and go.

A Simple Rule

You simply cannot nest scroll panes inside of other scroll panes (unless perhaps one only provides horizontal scrolling, while the other provides only vertical). When the user resizes your screen, you now have BOTH scroll panes competing to see who will scroll first in order to accommodate the smaller screen real estate. When this happens, several things might happen:

  • You might see “double scroll bars” as shown above
  • In some cases the screen may jitter and shake as Swing tries to recalculate the layout
  • Things like table headers, which are supposed to be fixed, may in fact scroll away due to the outer scroll pane
  • Some panels may fail to stretch correctly, so at larger sizes you’ll see blank space instead of panels stretching to fill remaining space.

So nested scroll panes is blunder #2. You need to selectively choose regions of your screens that will expand and contract, and only use scroll panes in those regions. These are generally things like trees, tables, and text areas, but could be other components.

And finally, never blindly assume customers will run your app at 1024×768. You must resize your windows, move splitters, and force your GUI into awkward sizes to see how it reacts under pressure.


2 Responses to “JScrollPane Blunders: Part 2”

basil Says:

Is there no way in Java to get the effect seen in Mac OS X Finder using the View by Column? It is a series of grids, each representing a deeper level in a hierarchy. Each grid is scrollable, and the group is scrollable when the number of grids is too great to fit on screen.

[...] three-part series by Eric Burke on do’s and do not’s of scroll panes. Read part 1, part 2 and part 3. A good rule of thumb would be to never use scroll panes for wrapping UI controls. Only [...]

Leave a Reply