Re: DoModal()
On Mon, 12 Jan 2009 14:14:50 -0500, David Wilkinson <no-reply@effisols.com>
wrote:
Joseph M. Newcomer wrote:
Note, however, that if anyone calls CDialog::OnOK(), they will call YOUR OnOK handler,
because it is a virtual method. Your OnOK() handler then calls CDialog::OnOK, which is
shown below. But if you call EndDialog(IDOK), then your OnOK() handler is NOT called, and
key behavior (such as the call on UpdateData(TRUE)) will not be executed. Therefore, it
should generally be considered inappropriate for YOUR dialog to call EndDialog(IDOK).
Joe:
I'm not quite sure what you are saying here, but the way I always saw it is that
calling the base class CDialog::OnOK() from your derived class OnOK() is the
wrong thing to do.
I do it like this
void CMyDialog::OnOK()
{
if (!UpdateData(TRUE))
{
return;
}
// my code goes here
EndDialog(IDOK);
}
I agree that's the correct pattern. If you chain to the base class version,
you will make redundant UpdateData and EndDialog calls.
But of course this violates your rule of never using UpdateData(). And it
violates it maximally, because I always do this.
If you're using ClassWizard to set up data variables, OnOK /must/ call
UpdateData. I once wrote a framework for dialog programs, and to make it
all a little cleaner, I did something like the following:
void BaseDialog::OnOK()
{
if (!UpdateData() || !AllowOK())
return;
... OK action is valid, more code here
}
Derived classes would never override OnOK. Instead, they'd override
AllowOK. They'd know that UpdateData had been called for them, and they
could expand on the transfer/validation performed by UpdateData.
--
Doug Harrison
Visual C++ MVP