Re: DoModal()
Joseph M. Newcomer wrote:
But this presumes that I would use DDV, which there is no way I would ever trust. The
kinds of validation I do are too complex for the naive DDV, and DDV does it at precisely
the WRONG place: when the user has clicked "OK". If I'm doing validation, the OK button
is disabled until the data is acceptable. I've found that this is far more humane, and it
allows the user to instantly see that something is wrong, instead of getting to the end,
hitting OK, and discovering (usually via a MessageBox that bears no resemblance to the
problem space) that something, somewhere, is wrong.
Years of cleaning up other people's code has convinced me that there are two fatal
patterns in building dialogs:
Postponing validation to OnOK
Using OnKillFocus validation that forces focus back to the offending control
When possible, I do keystroke-by-keystroke validation; when that is not possible,
OnKillFocus handlers PostMessage a validation request which merely flags invalid fields.
One useful technique is to enable tooltips, and for the IDOK button, the tooltip given
when the mouse hovers over the OK button is one of the reasons the button is disabled. The
users absolutely *loved* this one. I also tend to have a normally-invisible static
control or multiline edit control that will become visible (usually bright red background
with yellow letters, but it is always user-settable for the color scheme) that displays a
list of the errors. In one app, we had a ListBox where double-clicking the error put the
focus on the offening control. But I strongly believe, based on fundamental principles of
how human beings work, that OnOK validation is one of the poorest ideas in user interfaces
(cognitive psychology dictates the Principle Of Least Surprise as critical to user
interactions. This is because in our genetic past, things that surprised us tended to
kill and eat us, so we don't like surprises. If the OK button is enabled, it should mean
"DO IT!" and if something is wrong, we should not be allowed to click the OK button and
get a nasty surprise. Or several nasty surprises in sequence as we fix each of several
independent errors).
Joe:
Well I might buy all that, but the fact is that the MFC paradigm *does* use DDV
and *does* delay validation until OnOK(). In that context I would maintain that
it always a mistake to call CDialog::OnOK() from your override (unless you have
no validation beyond DDV, in which case you don't need an override).
Actually, the whole question of whether (and when) you should call the
superclass handler from your own handler is one of the most confusing aspects of
MFC, IMHO (even apart from the issue of modified parameters not being passed to
the "base class", which we have discussed before).
--
David Wilkinson
Visual C++ MVP