Re: MessageBox hangs app. AfxMessageBox

Subject: Re: MessageBox hangs app. AfxMessageBox
From: Joseph M. Newcomer <newcomer@flounder.com>
Newsgroups: microsoft.public.vc.mfc

For message boxes, popping them up in constructors is VERY dangerous.
This is because a constructor could be called before there is an HWND
object associated with the CWnd object, which can lead to all kinds of
problems. Never pop up message boxes in constructors.

The place to handle them is in OnInitDialog, and even then it is
questionable; if I have an initialization error, I will PostMessage a
notification to the dialog and abort initialization; when I process
the message, I will terminate the dialog. I try to avoid any
situation that would actually result in needing to do this because
dialogs should not spontaneously terminate themselves, they should
only be terminated by the user (special exception for timed-out
dialogs, but that's a rare and exotic situation).

When creating a modal dialog from any CWnd derived class, the parent
of the modal dialog (which includes MessageBoxes) should be the class
issuing the dialog. Otherwise, the world can become very confused.
I've never needed to do any kind of reflection or any special handling
to deal with message boxes from property pages (although I don't do
wizards, just tabbed property sheets), but the anomaly I see here is
that you are going to extra effort to do something very suspicious, so
that's the first thing I'd eliminate.

It is possible to really tricky things, but the more conventional you
try to be, the fewer problems you are likely to have. A lot of MFC
makes assumptions about how the software is designed, and you tread
outside those bounds with great caution, and generally expect to have
weird experiences if you do.

One of the most common errors I see is that someone sees a parameter
specification that says
          SomeAPI(SOMETHING * thing);
and immdialely arrives at the conclusion that the parameter must be a
VARIABLE of type SOMETHING*. This is not true; what it means is the
VALUE must be of type SOMETHING*, so if you declare
          SOMETHING t;
then the call
          SomeAPI(&t);
creates an EXPRESSION whose value is SOMETHING*. Note that no
allocation or deallocation via new/delete is required. I actually
have a sequence of slides in my Systems Programming course which shows
the cases
     SOMETHING * t;
     SomeAPI(t);
[fails because t is uninitialized]
     SOMETHING * t = new SOMETHING;
     SomeAPI(t)
[silly, and note the delete is missing!]
     SOMETHING * t = new SOMETHING;
     SomeAPI(t)
     ... use t
     delete t;
[works, but gratuitously complex and solves a problem which does not
need to be solved, and requires that all paths after the new SOMETHING
must effect a delete t or there will be a storage leak, so the code is
not robust]
     SOMETHING s;
     SOMETHING * t = &s;
     SomeAPI(t);
[works, but why introduce an unnecessary variable?]

Remember that the parameter specifications state SOLELY the TYPE of
the parameter, and have nothing to do with whether it is a variable!

               joe

On Sat, 10 Nov 2007 17:14:21 GMT, JC <elvis_is_king@bellsouth.net>
wrote:


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