Handling Window Events

A graphical window built with JFrame has a close box in its corner. When the user clicks it, something happens, but the outcome is not the same for every window. The program decides what that click means. In this article you will see a window respond to a close click, form a prediction about why, and then trace the cause back to a single setting. Whenever a window does not behave the way you expected, the same question applies: which close operation was set, and where was it set?

Think of the close click as an input that the window must answer. The answer depends entirely on the close operation stored on that window. The close operation is one of four JFrame constants, and each constant gives a different answer to the same question: what does the window do when the user clicks its close box?

Read the diagram from the top. The close click always reaches the same decision point, and the branch you follow is determined by the close operation that was set on the window. Each branch ends in a different terminal state: the program ends, the window stays open, the window is hidden while the program keeps running, or the window is disposed while the program keeps running. The diagram answers one question: what do the window and the program look like after the click?

The close operation is assigned by calling setDefaultCloseOperation on the window object and passing one of the JFrame constants. In the example program the call is placed outside the window's constructor, in the code that creates and configures the window. The source gives the reason: flexibility. A window class that fixes its close behavior internally forces that choice on every program that uses it.

The reason for keeping this decision in the creating code becomes clear with a hypothetical drawing application that opens several drawing windows at once. If closing one window ended the entire program, the user could not close a single drawing without losing the others. Because the close decision lives in the code that creates the window, the surrounding program can choose the behavior that fits its situation. A drawing application might choose a close operation for each window it opens, while a different program using the same window class could choose differently.

A JFrame offers four constants for the default close operation. They differ on two points: whether the program keeps running, and whether the window can come back. The subsections below take them one at a time.

Hiding and disposing both remove a window from the screen, so they look similar at first. The difference shows up in what you can do next. Trace the state of the window in each case. The diagram below follows a window through the close operations and the call that can show it again.

A hidden window is still in the middle of the lifecycle: calling setVisible(true) brings it back. A disposed window has no such path back in the source's description, because it has given back its resources and is finished. The diagram shows the difference as a branch with a return edge on one side and a terminal state on the other.

A program can also close a window on its own initiative. The source notes that the same permanent result as DISPOSE_ON_CLOSE is available by calling the instance method window.dispose(). The difference is who triggers it: the user clicking the close box in one case, and the program deciding to close in the other.

Most surprises with window closing come from assuming the wrong close operation is in effect. The items below are the patterns that cause the most confusion.

When a window does not behave the way you expected, follow the same steps each time: identify the observed outcome, match it to a branch of the close-box decision, and then find the line where the close operation was set.