Java Frames and Windows

Java programs often open a small window that asks a question, shows a message, or collects a piece of information. These windows are called dialog boxes. Java ships with ready-made dialogs through the JOptionPane, JColorChooser, and JFileChooser classes, and you have already met them earlier in the course. The Mandelbrot Viewer program uses dialogs of all three kinds.

Ready-made dialogs cover many common needs, but sometimes a program needs a window that asks a question or gathers information in a shape the standard classes do not offer. For those cases Java lets you build a custom dialog box of your own design. This article keeps one question in mind throughout: when a dialog is open, what is the rest of the program allowed to do?

Because of this structure, a dialog is a separate window on the screen in the same broad sense that a frame is a separate window. The JDialog class is very similar to JFrame. If you already understand how a frame is shown and populated, most of that knowledge carries over to a dialog. The difference that matters is not in how the window looks. It lies in how the window is attached to the rest of the program.

Every dialog box has a parent. The parent is either a frame or another dialog box, and it is the window that owns the dialog. Ownership is what separates a dialog from an ordinary independent window. The diagram below shows how a custom dialog sits in relation to its parent frame and to the JDialog class it extends.

Ownership has two consequences. First, the dialog closes automatically when its parent closes. Second, the dialog may float on top of its parent even when the parent is the active window. The dialog stays visually in front of the window that owns it. Together these effects make the dialog feel like a companion to its parent rather than a stranger that happens to be open at the same time.

A modal dialog is the common case, and all of the standard dialog boxes in Java are modal. This is why they feel direct: each one demands an answer before the program moves on. A custom dialog is modal when you choose that behavior, and the same blocking rule applies to it. The sequence below traces a user, a main window, and a modal dialog over time.

A dialog box is either modal or modeless. The other category, the modeless dialog, does not block the rest of the application. It behaves more like an independent window than a question that must be answered first. It can remain on screen while the user works in other windows, and the user can switch back and forth freely. The diagram below contrasts the two categories.

Notice what each category asks of the user. A modal dialog asks for attention now and holds the program until it gets it. A modeless dialog offers a window that can coexist with ongoing work. The ownership relationship from the previous section still applies to a modeless dialog: its parent still owns it, and it still closes when that parent closes.

The choice depends on what the dialog asks of the user. The source describes the two behaviors clearly, so the guidance below follows directly from them. The questions are a way of applying those descriptions to a concrete task; they are not a fixed rule set.