Re: Batch file and MFC (Properly Terminating Application)

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

For the cancel button, you would invoke the OnCancel() handler for the dialog. If you
don't write an OnCancel handler, the CDialog::OnCancel handler is invoked (OnCancel is a
virtual method invoked by the dialog receiving a WM_COMMAND(IDCANCEL) notification. The
CDialog::OnCancel handler will do and EndDialog(IDCANCEL) call, which will, within
Windows, ultimately issue a WM_QUIT, but you never see that. Nor should you.

The problem with WM_QUIT is that it stops the message pump dead. So no more messages can
be processed. What about that message that says "Prompt the user to ask if all data
should be saved"? Sorry. What about the clean shutdown of all threads? Sorry. What
about the sequence of messages handling the clean shutdown of the database or network.
Sorry. They're all gone. The program exits, leaving all kinds of things broken. There
are no protocol messages sent to the server about the network connection closing. There
is no chance to write out any buffered data, or properly close files (while the handles
will be closed, data which has been buffered in the app isn't flushed because that only
happens when you call the high-level close function, such as fclose, so the files are left
in indeterminate and possibly corrupt state). The server might do a rollback--losing all
the changes the user thought had been made--because the app closed without giving it a
clean close on its network connections. You bypass all possibility of any recovery
mechanism being viable for any purpose. Since you have no idea what is really required by
WM_CLOSE, this has all the value of doing ExitProcess(), which is to say, it is about as
clean as writing (LPBYTE)0 = 0; except that the null pointer assignment actually
generates a useful notification that the program is screwed up, whereas WM_QUIT quietly
screws up.

Don't confuse the mechanism for exiting the message pump with the policy for exiting the
message pump. The framework is responsible for implementing the policy; you just don't
know how it does it. The implementtion is ultimately a WM_QUIT message, but that's about
as important as knowing the ebx register holds the value of i during the for-loop during
one particular loop in one particular subroutine.

WM_QUIT is handled internally by the MFC framework, AFTER all relevant close operations
have been performed, You never issue it in the main GUI thread yourself. If you want to
close a non-dialog app, do a PostMessage(WM_CLOSE) to the main window. If you want to
close a dialog app, call CDialog::OnOK or CDialog::OnCancel (depending on which kind of
termination you want), but only if the user has invoked an operation that is supposed to
close the app.

You actually DO use WM_QUIT to shut down secondary UI threads, but that's a different
issue. And it must be done with care, preferrably from within the thread when it
determines that it is in a clean state to shut down.
joe


On 3 Feb 2007 19:34:42 -0800, "one-trick-pony" <worldofpain.aamir@xxxxxxxxx> wrote:

ABSOLUTELY POSITIVELY WRONG!!!!! NEVER, UNDER ANY CIRCUMSTANCES, POST
A WM_QUIT MESSAGE
FROM WITHIN THE MAIN GUI THREAD!!!! Just pretend you never heard of
WM_QUIT.


I am confused about this line. Lets assume, I create the simplest
type of Dialog based application with 2 buttons. One button caption
is Hello and second button is Cancel. When user clicks Hello button a
simple message box pops up and says Hello There! ...easy enough. Now
user clicks on Cancel button and application exits. The two buttons
are created by default in MFC Dialog based application -Ok and
Cancel . Assuming, I deleted Ok button and didnt write any code to
support the Cancel button. Cancel button is created by default and it
always makes application exit without having to code it. So when I
click on it, there was only 1 main thread and I exited out of Main GUI
thread. It seems your comment is wrong but I know there is gap in my
understanding. I thank you for your help.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Quantcast