Re: Upgrade Anxiety
Joe:
Inline:
Joseph M. Newcomer wrote:
In the entire history of MFC, there has never been a sane reason that handlers and control
variables were ever made public. There was a bad reason: the very weak ClassWizard
parser, but that was not really a good justification for creating bad code. Adding
control variables defaults to "public", which is wrong, and handlers are put in as
"public", which makes no sense whatsoever.
I know you do not like UpdateData() and value member variables, but if
you do use them, then it is useful to make the variables public, because
it allows use of the paradigm
CMyDialog dlg;
dlg.m_nThis = nThis;
dlg.m_nThat = nThat;
if(dlg.DoModal() == IDOK)
{
nThis = dlg.m_nThis;
nThat = dlg.m_nThat;
}
Not very good OOP, but it allows you to see from the client code exactly
what the dialog does. It even allows simple dialogs to be designed
entirely in the resource editor, without writing any code.
But actual control variables (CWnd derived) should never be public, I agree.
And, as you point out, the fact that it just sort of randomly adds things into the file
instead of putting them in sensible places means that you have to go in and clean up the
header file to group handlers, variables, and so on into what makes logical sense to
someone reading the header file. VS6 had this right, even if it was for the wrong
reasons.
Unfortunately there is no going back now, because there is a lot of code
written without the ClassWizard-delineated sections that kept everything
in the right place.
One of the most annoying things is always putting new DDX.. statements
at the end of the DoDataExchange(), which can mess things up if you have
other code there besides DDX/DDV statements.
<snip>
--
David Wilkinson
Visual C++ MVP