Modal vs Modeless Dialogs
A modal dialog, created with CDialog::DoModal(), disables its owner window and blocks the caller until the dialog is dismissed, running its own nested message loop internally — the calling code literally pauses on the DoModal() call until EndDialog() (via OnOK/OnCancel or a custom handler) is invoked, making modal dialogs the natural choice for interactions like a Save-changes confirmation that must be resolved before the app can proceed. A modeless dialog, created with CDialog::Create(), returns immediately, leaves the owner window fully interactive, and requires the caller to manage the dialog object's lifetime explicitly since there's no blocking call to fall back on.
Cricket analogy: It's like a rain delay that halts the entire match until the umpires' pitch inspection is complete, versus a routine drinks break where play continues around the ground while it happens.
Managing a Modeless Dialog's Lifetime
Because Create() returns immediately, the CDialog-derived object must be heap-allocated with new and kept alive by the owner (commonly as a member pointer), since a modeless dialog destroyed prematurely would leave a dangling window; the conventional pattern overrides PostNcDestroy() to call 'delete this' after the window is fully destroyed, self-cleaning once the user closes it, while the parent typically calls ShowWindow(SW_HIDE) rather than DestroyWindow() from a Close button handler if the dialog might be reopened, or calls DestroyWindow() explicitly when it truly should go away.
Cricket analogy: It's like a substitute fielder brought on mid-match staying on the field under the captain's management until explicitly told to leave, rather than wandering off the boundary unsupervised.
Choosing Between the Two
Practical Decision Criteria
The decision usually comes down to whether the user needs to keep working with the rest of the application while the dialog is open: a Find/Replace dialog is classically modeless because users want to keep editing the document while it stays visible, whereas an Options/Preferences dialog is almost always modal because applying settings mid-interaction with the main window would create confusing partial states; a further nuance is that a modal dialog can still be made 'application modal' versus 'system modal', but MFC's DoModal() defaults to disabling only the owner window, not the entire desktop.
Cricket analogy: It's like a drinks break that lets the game continue in a loosely paused state versus a formal appeal review that fully stops all play until resolved — the choice depends on whether ongoing action and the decision can safely coexist.
// Modal usage — blocks until dismissed
void CMainFrame::OnOptionsPreferences()
{
COptionsDlg dlg(this);
if (dlg.DoModal() == IDOK)
{
ApplySettings(dlg.m_settings); // safe: dialog is fully closed by now
}
}
// Modeless usage — non-blocking, lifetime managed by the owner
class CMainFrame : public CFrameWnd
{
CFindReplaceDlg* m_pFindDlg = nullptr; // heap-allocated, tracked as a member
afx_msg void OnEditFind();
DECLARE_MESSAGE_MAP()
};
void CMainFrame::OnEditFind()
{
if (m_pFindDlg == nullptr)
{
m_pFindDlg = new CFindReplaceDlg();
m_pFindDlg->Create(IDD_FINDREPLACE, this); // returns immediately
}
m_pFindDlg->ShowWindow(SW_SHOW);
m_pFindDlg->SetFocus();
}
// In CFindReplaceDlg:
void CFindReplaceDlg::PostNcDestroy()
{
CDialog::PostNcDestroy();
delete this; // self-cleanup once the window is truly gone
}
Because DoModal() blocks the calling thread with its own nested loop, it's safe to read the dialog's member variables for results immediately after the call returns — the dialog and all its data are guaranteed to be in their final state by then, unlike with a modeless dialog.
Never call 'delete' directly on a modeless dialog object from outside it while its window still exists — let PostNcDestroy() perform the 'delete this' after DestroyWindow() has actually torn down the HWND, otherwise you risk a window with an already-freed C++ object still receiving messages.
- DoModal() blocks the caller with a nested message loop and disables the owner window until EndDialog() runs.
- Create() for a modeless dialog returns immediately and leaves the owner window fully interactive.
- A modeless dialog is typically heap-allocated and tracked by a member pointer since there's no blocking call to rely on.
- PostNcDestroy() commonly performs 'delete this' to self-clean a modeless dialog once its HWND is truly destroyed.
- Modal dialogs suit interactions that must resolve before the app can safely continue, like confirming destructive settings.
- Modeless dialogs suit ongoing tools like Find/Replace that should stay usable alongside continued document editing.
- Reading a modal dialog's member variables right after DoModal() returns is safe; a modeless dialog's data may still change asynchronously.
Practice what you learned
1. What is the key behavioral difference between DoModal() and Create() for an MFC dialog?
2. Why is a modeless dialog typically heap-allocated with new rather than created as a local stack variable?
3. What is the conventional purpose of overriding PostNcDestroy() in a modeless dialog class?
4. Which type of dialog would best suit a Find/Replace tool that should stay open while the user keeps editing a document?
5. Why is it safe to read a modal dialog's member variables immediately after DoModal() returns?
Was this page helpful?
You May Also Like
Dialog-Based Applications
How MFC's dialog-based application template uses DoModal and DDX/DDV to build a self-contained UI without a document/view frame.
Message Maps
How MFC's message-map macros build a static dispatch table that replaces a hand-written WndProc, plus how command routing and UI updates work on top of it.
MFC Controls Overview
A tour of MFC's C++ wrapper classes for Windows common controls, how to bind them via DDX_Control, and practical examples with CListCtrl and CComboBox.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics