Have you encountered dialogs that look “right” but annoy users?
Every developer knows how easy it is to turn a simple settings window into a maze of unnecessary buttons, strange modality, and an unexpectedly “frozen” application.
This chapter reveals why a dialog window is not a “form with fields,” but a key mechanism for managing attention and workflow. Here you’ll discover the practical approach used by professional developers: how to make users not think about the dialog — while keeping the application predictable, fast, and clean.
We’ll examine 2 modes (modal/non-modal) and their consequences, you’ll see working patterns with exec() and show(), as well as techniques for managing window lifecycle (including Qt::WA_DeleteOnClose). Plus — a set of Qt’s standard dialogs: QFileDialog, QFontDialog, QColorDialog, QInputDialog, QProgressDialog, QWizard, and the “heavy artillery” QMessageBox.
Skip this chapter, and it’s very easy to “gift” users with windows that interfere with their work.
This chapter includes ready-to-use code examples.
Chapter Self-Check
Why is static object creation acceptable for modal dialog windows, but only dynamic creation recommended for non-modal windows with the show() method?Answer
Correct answer: The exec() method blocks code execution until the window closes, so a static object won’t be deleted prematurely. The show() method returns control immediately, and if the window is created statically, the object will be destroyed when it goes out of scope, even if the window should still be visible.
Why set the Qt::WA_DeleteOnClose attribute for non-modal windows, and what happens without it?Answer
Correct answer: The attribute guarantees automatic memory release when the user closes the window. Without it, a dynamically created non-modal window will remain in memory after closing, leading to a memory leak.
Why should menu commands that invoke dialog windows end with an ellipsis (e.g., “Open…”)?Answer
Correct answer: The ellipsis serves as a visual cue to the user that pressing the command won’t execute the action immediately but will open a dialog window for additional input or confirmation, improving interface predictability.
Why is qApp->processEvents() called in the loop processing a lengthy operation with QProgressDialog?Answer
Correct answer: Calling processEvents() forces GUI event processing before each loop iteration, allowing the progress window to update, respond to Cancel button presses, and prevents the interface from “freezing” during a lengthy operation.
Why does a dialog window without a parent center on the screen, while a window with a parent centers relative to the parent widget?Answer
Correct answer: Centering relative to the parent provides contextual proximity and logical connection between the main window and the dialog. Windows without a parent center on the screen as independent interface elements.
Why is scrollable content undesirable in dialog windows, and what solution is proposed?Answer
Correct answer: Scrolling complicates navigation and reduces visibility of controls. Instead, it’s recommended to logically group elements and arrange them using tabs (QTabWidget), allowing users to see all content without scrolling.
In which situations is a modal dialog window preferable to a non-modal one?Answer
Correct answer: Modal windows are preferable when the application cannot continue working without the user’s decision — for example, during critical errors, when saving data before closing, or choosing mandatory operation parameters.
How does the QColorDialog::getColor() method signal that the user pressed Cancel, and why was this approach chosen?Answer
Correct answer: The method returns a QColor object, and isValid() is called on this object — if it returns false, it means the Cancel button was pressed. This approach allows returning both the selected color and the operation status through a single return object.
What happens if the clicked() signals of Ok and Cancel buttons aren’t connected to the accept() and reject() slots in a modal window?Answer
Correct answer: The exec() method won’t be able to return correct values of QDialog::Accepted or QDialog::Rejected when buttons are pressed, making it impossible to determine the user’s choice in the calling code.
Why pass a value of 0 to the QProgressDialog::setMinimumDuration() method, and how does this affect behavior?Answer
Correct answer: A value of 0 indicates that the progress window should display immediately without delay. By default, the window shows only if the operation takes more than 3 seconds — this prevents window flickering during quick operations.
What does QFileDialog::getSaveFileName() return if the user presses Cancel, and how to check this?Answer
Correct answer: The method returns an empty string (QString). This can be checked with the isEmpty() method — if it returns true, it means the user canceled the file selection, and the save operation shouldn’t be performed.
Why should a message box with multiple buttons always define a Cancel button and set setEscapeButton()?Answer
Correct answer: Users often press the Esc key to cancel an action, and without setting setEscapeButton(), such a press can lead to unpredictable behavior or selection of an unexpected button, worsening the user experience.
Why is it recommended to call raise() and activateWindow() after calling show() for non-modal windows?Answer
Correct answer: These methods ensure that the non-modal window will be visible above the main application window and receive input focus, solving the problem of window hiding that can occur on some platforms.
Practice Assignments
Easy Level
User Data Input Dialog
Create a modal dialog window for entering user information: name, age, and email. After closing the window via the OK button, the main window should display the entered data in a QMessageBox. When Cancel is pressed, data should not be displayed.
Hints: Inherit the class from QDialog. Use QLineEdit for text fields and QSpinBox for age. Connect OK and Cancel buttons to accept() and reject() slots. Create getter methods to retrieve entered data. Check the exec() result in the main window.
Medium Level
Non-Modal Settings Window with Saving
Create a non-modal application settings window with tabs: “General”, “Interface”, and “Advanced”. Each tab should contain several checkboxes and comboboxes. Implement “Apply”, “OK”, and “Close” buttons. The window should remember its position and appear in the same location when reopened. Use hide() instead of closing the window and Qt::WA_DeleteOnClose for correct memory management.
Hints: Use QTabWidget for tabs. To save position, override closeEvent() and call hide(). Store a pointer to the settings window in the main class. The “Apply” button should signal changes without closing the window. Use QSettings to save settings between runs.
Hard Level
Project Creation Wizard with Validation
Implement a wizard dialog window (QWizard) for creating a new project with four pages: project type selection, specifying name and path, build settings configuration, and a final confirmation page. Add validation on each page: the “Next” button should be unavailable until the user fills in all required fields. Implement page navigation considering choices on previous pages (e.g., if “Console Application” type is selected, skip the GUI settings page). After wizard completion, create a file with project settings and show QProgressDialog when “creating” the project structure.
Hints: Use QWizardPage with overriding validatePage() and isComplete() methods. For conditional transitions, use setField() and field() to exchange data between pages or override nextId(). For dynamic activation of the “Next” button, connect textChanged() or currentIndexChanged() signals to the completeChanged() slot. On the final page, call QFileDialog::getSaveFileName() to choose the configuration save location.
💬 Join the Discussion!
Got a handle on modal and non-modal windows? Have questions about when to use QDialog::exec() versus show()?
Share your experience working with dialog windows, tell us about unusual use cases of QWizard or QProgressDialog, or help other readers understand the nuances of memory management when dynamically creating windows!
Let’s discuss: Which dialog window design principles do you consider most important? Have you encountered cases where Qt’s standard dialogs didn’t fit and you had to create custom solutions?