Standard Dialog Boxes in Java

Most programs that need to ask the user something can rely on dialogs Java already provides. Earlier in the course you met three of them: JOptionPane, JColorChooser, and JFileChooser. The Mandelbrot Viewer program uses dialogs of all three kinds. These ready-made dialogs cover many common needs.

Sometimes, though, a program needs a window that asks a question or collects information in a shape the standard classes do not offer. For those cases Java lets you construct a custom dialog box of your own design. This article looks at what a custom dialog is built from, how its relationship to the window that opened it shapes its behavior, and the two behavioral categories a dialog can belong to.

In Java, a custom dialog box is defined by writing a subclass of the JDialog class. Because the dialog is a subclass, the work of putting content into it and arranging that content happens in your own class, while JDialog supplies the general behavior of being a window. A dialog is therefore 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. The difference that matters is not in how the window looks but in how it is attached to the rest of the program. That attachment is the subject of the next section.

Think of the custom dialog class as the place where your content lives, and JDialog as the base that makes it behave like a window. You write the content; JDialog provides the window behavior.

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. Two consequences follow directly from it.

The first consequence concerns the lifetime of the dialog: it closes automatically when its parent closes. The second concerns the screen: a 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, so the relationship is visible to the user as well as enforced by the program. 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 dialog box is either modal or modeless. Start with the modal case, since it is the one you will meet most often. A modal dialog, once it appears on screen, blocks the rest of the application. The application cannot be used in other ways until that dialog box has been dismissed. Read the sequence below from top to bottom to see the order in which the user, the main window, and the dialog interact.

The other category is the modeless dialog. A modeless dialog does not block the rest of the application. Because of that, 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 choice depends on what the program needs from the user at that moment. Ask whether the program can proceed without an answer. If it cannot, a modal dialog fits, because it holds the program until the answer arrives. If the window is something the user should keep open while doing other work, a modeless dialog fits better.

Dialog behavior is easy to misjudge because the windows look alike. The mistakes below come up often when learners first build custom dialogs.