Re: Managing a project as it scales

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

On Tue, 27 Dec 2005 13:39:08 -0000, Gerry Quinn
<gerryq@xxxxxxxxxxxxxxxxxxx> wrote:

>In article <e133q1hcmkil683i4phh4eqesubn5s3dqq@xxxxxxx>,
>newcomer@xxxxxxxxxxxx says...
>
>> No use of UpdateData. No exceptions. No use of GetDlgItem. Occasional rare exceptions
>> for arrays of identical controls, such as buttons (this exception can come up as often as
>> once every two years).
>
>Everything made sense apart from this.
>
>I don't use UpdateData() much, but an example would be a screensaver in
>which a little window in the dialog shows an instance of the
>screensaver running with the current dialog settings. Another example
>might be where controls interact, e.g. five sliders that must add up to
>a constant total, so if one increases the others must be decreased
>automatically.

The key thing to realize is that UpdateData is a blunt instrument - it's
all controls that participate in DDX/DDV or nothing. See this message for
more on this:

http://groups.google.com/group/microsoft.public.vc.mfc/msg/1beb7cdaf010b0c6

>As for GetDlgItem(), I use it all the time. Why not? Suppose you want
>to set the text of a read-only text control - GetDlgItem() seems as
>good a way of accessing it as any.

Besides inconvenience, there are two problems with using GetDlgItem instead
of binding variables to controls:

1. GetDlgItem can fail and throw an exception at an indeterminate time, the
first time it's called on a control, whereas control variables are all
bound during OnInitDialog.

2. GetDlgItem will return a pointer to a temporary CWnd that isn't
necessarily of the desired type. For example, for an edit control
identified by IDC_EDIT that isn't bound to a CEdit, GetDlgItem(IDC_EDIT)
returns a temporary CWnd* instead of a CEdit*. This can have negative
repercussions if CEdit handles a message differently than DefWindowProc, or
if you cast it to CEdit* and use parts of it (member variables, virtual
functions) that don't exist in CWnd. (NOTE: The MFC CEdit class and other
MFC control classes are NOT subject to this problem, but you can still
demonstrate the type shenanigans with RTTI.)

Binding an HWND to a control variable of the proper type avoids these
problems and makes sending messages to the window a good bit more
convenient. In addition, binding ensures that if you do need to call
GetDlgItem, you get a pointer to the CWnd part of the control object you
bound to the HWND, which you can safely downcast to that object's type.

--
Doug Harrison
Visual C++ MVP
.

Quantcast