Re: ? Post Window (Dialog) Creation Flag
On Mon, 11 Sep 2006 14:29:42 -0400, Joseph M. Newcomer
Actually, I *do* advocate that every single control that is manipulated should be given a
control variable. Why not? Does it ever make sense *not* to do this? Why have two
completely orthogonal mechanisms to handle this. And the control variables work correctly
if you decide to override SetWindowText, whereas the GetDlgItem approach will cause
subclassed objects to fail completely. Another failure mode.
If the control has been subclassed, that is, bound to an MFC control
variable, GetDlgItem will return a pointer to the CWnd part of that control
variable. You can call virtual functions through this pointer, and all will
be well. The problem is, SetWindowText is not virtual and thus cannot be
overridden. It can only be hidden, and it's a bad practice to hide public
member functions, because among other things, it can set up wrong
expectations concerning their behavior. They are not polymorphic, and you
should not expect them to act as if they are. It is a mistake to define
your own SetWindowText. If you handle this scenario properly, it won't
matter if you use GetDlgItem or not for a bound control, but it would be
pretty rare to use GetDlgItem on a bound control, so it's kind of a moot
point. See below for more.
"Robust under maintenance"
is critical. Therefore, I should be able to subcass a CStatic, override SetWindowText,
Again, you cannot override SetWindowText. It is not possible.
change the declaration, and recompile, and everything will work correctly. E.g.,
void CMyStatic::SetWindowText(LPCTSTR s)
if(old == s)
If I had been doing this with GetDlgItem, I have to go and change all kinds of places in
my code; with a control variable, I have to change exactly ONE place, the declaration of
the variable! So I would *NEVER* consider using GetDlgItem except in some very rare and
exotic situations (my claim is that if you are writing more than on GetDlgItem per year,
you are not using MFC correctly)
This is a false problem which exists only because this is the wrong way to
do this. It is through message maps that MFC achieves polymorphism for
messages, and the correct way to do this sort of thing is to handle the
Windows message, in this case, WM_SETTEXT. This way, you can call
SetWindowText through a pointer to any base in the class hierarchy, and you
can even use SendMessage(hWnd, WM_SETTEXT).
Visual C++ MVP