Re: Upgrade Anxiety

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

See below...
On Mon, 07 Jan 2008 11:39:50 -0500, David Wilkinson <no-reply@xxxxxxxxxxxx> wrote:

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
***
Note that I carefully said "control variables". Data variables make sense for the reason
you point out, but data variables were not part of the discussion. And I have no problem
with using the *implicit* UpdateData calls that happen from OnInitDialog and OnOK
****

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.
****
Sure there is. New markers can be added, and new versions will use those markers. Old
code can have them hand-edited in; if they're there, they are honored; if they are
missing, stuff gets added to the end. Fully upward-compatible! A marker like

protected: //{{Control variables}}
or
public: //{{ControlVariables}}

would work perfectly well. So there is no harm in adding something intelligently
designed, because it will not break existing code, but new code can take advantage of it,
and old code can be modified to support it!
****

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.
****
Yes, but to do otherwise would have required DESIGN, something woefully absent. As I've
said before, I strongly believe that software evolves, because there is so little evidence
of Intelligent Design in it.
joe
****

<snip>
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Signs of Deliberate Artifact?
    ... The argument from design was demolished more than 200 years ago: ... Here's Kant arguing against the teleological argument for the existence ... and human reason can never do without ... that is, the nature of different things could never spontaneously, by ...
    (talk.origins)
  • Re: OT - Cant we all agree????
    ... The reason is that so many decent, honorable, ... I've observed your thoughtful and measured responses to Powell over ... Jeff is who he is. ... Is he the most important design engineer in the ...
    (rec.music.classical.recordings)
  • Re: OT - Cant we all agree????
    ... posters, why is it that I keep wandering into threads which they have ... The reason is that so many decent, honorable, ... I've observed your thoughtful and measured responses to Powell over ... Is he the most important design engineer in the ...
    (rec.music.classical.recordings)
  • Re: OpenVMS Seminar in Toronto (2005-02-24) a few points
    ... > of the alpha systems, except the DS15, were essentially completely ... > designed before the HP-Compaq merger. ... > engineers did not have access to the design specs from the other group. ... that others have good reason to feel differently about. ...
    (comp.os.vms)
  • Re: Quad Core PC for less than a Mac Mini
    ... All the design work is done by the MB and case manufacturers. ... only a dual core on this page, no CPU for this motherboad can be ... Because *all* of the CPU options for this motherboard suck. ... So your answer is you're just bending over backwards to find a reason ...
    (comp.sys.mac.advocacy)