Naming Conventions

Microsoft has some weird ideas about naming conventions. Hungarian notation was invented in the days before C had prototypes and thus cross-module checking. It probably had some utility in the days before C resembled a real programming language. It has absolutely no value today, and should be avoided. I find the m_ convention for member variables equally insane. I use it only in limited situations, in particular, only for values associated with controls. I only need value variables for controls whose values are passed into the dialog from outside, or which are passed back to the caller. Since I rarely do this, the occurrence of m_ variables in my code is very, very low.

There are other conventions I use. For example, I prefix the control variables with "c_". This indicates that it is a control variable. It is necessary to use a different convention than "m_", because some controls can have both a control variable and a value variable. In addition, it is often useful to be able to name the caption associated with some controls, such as an edit control. This is useful if you have to enable/disable the controls. Consider the case of an edit control, c_Text, which has a static control which is the caption. I use the prefix "x_" to indicate the caption. This introduces much sanity into the world. If I want to preload the text control by passing the value in, I create a value variable, m_Text. To access the control, I create a control variable, c_Text. To access its caption, I create a control x_Text. I never access the m_ variable within the dialog, unless I've provided a "reset to initial state" button which resets the control to its initial value. There is no need to access the value variable. If accessed, I only read it.

This means that the DDX calls will look something like

DDX_Control(pDX, IDC_TEXT, c_Text);
DDX_Text(pDX, IDC_TEXT, m_Text);
DDX_Control(pDX, IDC_TEXT_CAPTION, x_Text);

To enable or disable the text control and its corresponding caption you can then write something like

void CMyDialog::updateControls( )
    {
     BOOL enable;
     enable = ... 
     c_Text.EnableWindow(enable);
     x_Text.EnableWindow(enable);
    }

Note how clear this is. Easy to write, easy to understand, easy to maintain. What's that updateControls method? That's another essay!

Summary

The GetDlgItem method has limited usefulness in writing MFC code. If you write it, there is an excellent chance you are simply not using MFC correctly. Certainly there are exceptions, and I show one in my essay on dialog control managment. But such instances are rare. A well-written MFC application will have no gratuitous instances of GetDlgItem, anywhere, and no instances of UpdateData in any modal dialog, ever.