Creating Custom JPanel Components

Imagine a card game where you look at one playing card and must guess whether the next card will be higher or lower in value. Aces count as the lowest card in this game. Three correct guesses win the round, and a single wrong guess ends it. A text-based version of this game only needs the console. A graphical version needs a window that shows the cards, displays a message to the player, and offers buttons for making predictions and starting a new game.

Building that window is a design problem before it is a coding problem. You have to decide what goes where, which object owns the drawing, and which object reacts when the player presses a button. This article works through those three decisions in order, starting with the layout of the main window. Before reading on, pause and ask yourself: the window has a large area for the cards and message, and a row of three buttons. Which part of the window should the large area occupy?

A BorderLayout divides its container into five regions named NORTH, SOUTH, EAST, WEST, and CENTER. You place a component into one of these regions, and the layout positions it there. You do not have to fill every region. Any region you leave unused stays empty and contributes no visible content, so the design does not need a component for it.

Read the diagram as a frame around the window. NORTH runs along the top, SOUTH along the bottom, WEST down the left side, EAST down the right side, and CENTER fills whatever room remains in the middle. In the card game, only two of these five regions are used. The drawing surface goes in CENTER, and the subpanel holding the buttons goes in SOUTH. NORTH, EAST, and WEST are left empty.

The card game is built from two JPanel classes that play different roles. The outer panel is HighLowGUI, which is a subclass of JPanel. Its constructor creates the other components, sets up event handling, and lays out the components in the BorderLayout. The inner panel is a nested class named CardPanel, which is also a subclass of JPanel. CardPanel is the drawing surface, and it sits in the CENTER region of the outer panel.

Notice that the button subpanel is a child of the main panel's layout, and the three buttons live inside that subpanel. The main panel does not place the buttons directly; it places the subpanel in SOUTH. This nesting keeps the button row together as one unit inside the larger window.

Subclassing JPanel lets you attach behavior to a panel that the standard class does not provide. The card game's drawing surface does not use ready-made components for the cards or the message. Instead, the cards and message are drawn with the graphics context inside the panel's paintComponent() method. A custom subclass is the natural home for that code, because the drawing logic belongs to the same object that is responsible for the display.

Event handling is the link between a user action and the code that responds to it. When the player clicks a button, the event must reach the object that knows what to do. In this design, the drawing surface listens for events from the three buttons. That means the buttons are not the ones deciding the outcome. The buttons only report that they were pressed, and the listening object takes it from there.