Re: getWindowText in Child Dialog
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Thu, 08 Sep 2005 03:57:06 -0400
In general it is extremely poor style to reach into a child dialog and manipulate a
control. This violates so many issues of good programming style it is hard to imagine why
anyone would ever consider doing it. Look at any good book on C++ design patterns and it
should be clear why this is the Worst Possible Way to manipulate any kind of dialog. I
recently rewrote a course in which the modeless dialog knew the view that called it and in
its PostNcDestroy reached out into the view and set its dialog-pointer to NULL. This is
the complementary problem. Dialogs should be opaque, and the only visible variables set
should be at initialization, at termination, and in the case of modeless dialogs, at the
Apply button. Controls are never to be considered visible under any circumstances (the
fact that ClassWizard declares them public is a design failure of ClassWizard and must be
treated as such; in VS.NET I always declare them protected, and had any intelligence been
applied the the VS.NET ClassWizard design, this would have been the default!). C++
purists will argue that even setting and reading public variables is offensive style, and
more and more I'm falling into that camp, because I've been done in so often myself; you
supply methods to set and get values of interest. A dialog cannot see any variables
outside its member variables; it never sees, touches, or manipulates any global or static
variables unless (a) they really are shared state, in which case they are static members,
or (b) they are declared with the static const qualifiers and represent compile-time
tables local to the module.
If you need to manipulate a control, the ONLY way is to write code to do it in the
modeless dialog itself. Then supply methods that are called to handle this. Do not argue
either code size or efficiency, since neither of these is a concept even remotely worthy
of discussion in such cases.
It is nobody's business but the dialog's how it implements its internal state, and
thinking you have the right to manipulate that state explicitly is always a mistake.
Example: you have 15 radio buttons. You decide to replace the radio buttons with a
droplist instead. This should be completely transparent to the caller, who will simply
ask that a selection be made or the current selection retrieved. This selection value
will be completely divorced from the representation as radio buttons or drop list, and
private to the control.
Get rid of every such manipulation. All of them. Gone. Use methods, and only methods.
Then, make sure that the object you are calling is the same object you think you are
calling. THis looks like you have two different objects, one initialized and one not.
I've been using modeless dialogs for years, and never saw anything like this happen, so I
strongly suspect it is not VS.NET (where I'm also doing it!) but a bug in your program,
most likely getting more than one instance pointer, and using the wrong one. But if you
use methods you have a chance of debugging the problem, but if you do direct manipulation
the debugging becomes a serious nightmare.
On 4 Sep 2005 16:22:18 -0700, "djohnson" <programmer123@xxxxxxx> wrote:
>Further, I added the a public variable (int m_testInt) to the child
>dialog and set it to 5. It returns 5 nicely when called from the
>child, but when called from the parent it returns 0, no errors, and
>these public variables do show up in autocomplete so they appear valid.
> Nothing I can think of that I wrote could have wiped out the
>variables' values but I am wondering if some code auto generated by VS
>.NET might have.
>Any more help would be greatly appreciated.
Joseph M. Newcomer [MVP]
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Re: getWindowText in Child Dialog
- From: djohnson
- Re: getWindowText in Child Dialog
- Prev by Date: Re: changing colours of push buttons on dialog box
- Next by Date: bring me out of the MSCHART, please
- Previous by thread: Re: getWindowText in Child Dialog
- Next by thread: Re: getWindowText in Child Dialog