Re: DoModal()
Doug Harrison [MVP] wrote:
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:
Yes that is a nice way to do it. But wouldn't it just be
void BaseDialog::OnOK()
{
if (!UpdateData() || !AllowOK())
return;
EndDialog(IDOK);
}
There are similar problems with OnInitDialog(), but they are not so easy to deal
with, because CDialog::OnInitDialog() is a more complex function than
CDialog::OnOK(). So on occasion I have done
BOOL CMyDialog::OnInitDialog()
{
CDialog::OnInitDialog();
// my code goes here
UpdateData(FALSE);
return TRUE;
}
Part of the problem is that the DDX_CONTROL parts of DoDataExchange() cannot be
separated from the control initialization parts.
--
David Wilkinson
Visual C++ MVP