Adding Actions to Buttons in Java GUI Programming

This article works from a real example rather than from a list of rules. The example is the constructor of a Swing application that draws with the mouse and offers a small toolbar at the top of the window. The toolbar holds three color choices, presented as radio buttons, followed by a separator and a clear button.

Before reading any explanation, try to form your own picture of the window. What will it look like, and in what order will its pieces appear? Make that prediction now, because the gap between what you expected and what the code actually does is where debugging begins.

The goal of this article is to connect each line of that constructor to one visible or structural result. Once you can do that, you can also find the exact line where a toolbar behaves differently from what you expected, which is the skill that matters most when a GUI does not look right.

A toolbar in Swing is created with new JToolBar(). Creating the object does not make it visible on its own. It becomes part of the window only when it is placed into a container, and the components it holds are added to it with add calls. Each add call contributes one item to the toolbar.

The toolbar in the source example holds, in order, three color radio buttons, a separator, and a clear button. The source excerpt describes this layout, and the important rule it demonstrates is that components appear on the toolbar in the order their add calls run. Swing does not reorder components for you, and nothing about a button's purpose changes its position.

Think of the toolbar as a row of numbered slots. Each add call fills the next free slot, moving from left to right. Changing the order of the add calls changes which component ends up in which slot, while the components themselves stay the same.

The diagram reads as the result of five add calls made in the order shown in the sketch. The clear button sits at the far right end because its add call runs last. If a later edit moved the clear button's add call above the color buttons, the clear button would move to the left end. The toolbar would not complain; it would simply show the new order.

A toolbar must be placed in a container to appear in a window. The source describes this placement as an add call that includes a region name, such as BorderLayout.NORTH. That region name tells the container where the toolbar should go. BorderLayout.NORTH places the toolbar along the top edge of the container, and the CENTER region is left for the main drawing area.

The toolbar itself does not decide where it goes. The container's layout manager makes that decision, based on the region name given in the add call. The same toolbar object placed under a different region name would appear somewhere else in the window.

The three color choices are radio buttons. Radio buttons are meant to offer mutually exclusive options: the user picks one color, and picking another should release the first. Placing buttons next to each other on a toolbar does not create this behavior. Swing does not provide it automatically, so the grouping must be declared.

In this example the grouping is declared with a ButtonGroup. The code creates one group object and passes that same group to each color button. The group, not the individual buttons, is responsible for the rule that only one choice can be selected at a time.

Each color button is created by a call to makeColorRadioButton. That helper takes the color, the shared group, and a boolean. The source excerpt does not show the body of this helper, so this article does not describe how it uses the boolean internally. The excerpt does show that the red call passes true, the green and blue calls pass false, and all three calls share the same group.

The diagram shows that the group holds one current selection. Clicking green releases red, because the group allows only one of its buttons to be selected. The transitions shown are the logical behavior the group enforces; the excerpt itself describes the group's purpose rather than the internal mechanism.

A useful way to read any Swing constructor is to walk through it one line at a time and write down, for each line, what has been created and where it now sits. The source recommends exactly this: trace the constructor line by line and compare each line's effect with what you expected. The first line that diverges from your expectation is the failure location.