- Forum
- Windows Programming
- with or without WM_CLOSE?
with or without WM_CLOSE?
I found in a Modeless Dialog Box Procedure, the WM_CLOSE is necessary otherwise it can close.
but in a window procedure, the WM_CLOSE is unnesassary, just WM_DESTROY, why?
ps: Is there any difference between WM_COMMAND and WM_LBUTTONDOWN? I found in a code, it WM_COMMAND WM_LBUTTONDOWN do a thing in 2 parts.
why a dialog box procedure default return false?(true doesn't work)
but in a window procedure, the WM_CLOSE is unnesassary, just WM_DESTROY, why?
ps: Is there any difference between WM_COMMAND and WM_LBUTTONDOWN? I found in a code, it WM_COMMAND WM_LBUTTONDOWN do a thing in 2 parts.
why a dialog box procedure default return false?(true doesn't work)
WM_CLOSE gives you a change to cancel the close.
By the time WM_DESTROY is being called, it's all over.
WM_COMMAND is a general packet manager for passing on menu selections. So a typical WM_COMMAND handler will have menu option handlers in it.
A WM_LBUTTONDOWN message just tells you that the left mouse button was pressed. It is not the same as WM_COMMAND.
A dlgproc should return TRUE.
By the time WM_DESTROY is being called, it's all over.
WM_COMMAND is a general packet manager for passing on menu selections. So a typical WM_COMMAND handler will have menu option handlers in it.
A WM_LBUTTONDOWN message just tells you that the left mouse button was pressed. It is not the same as WM_COMMAND.
A dlgproc should return TRUE.
#1
A dlgproc should return TRUE if it processes the message, otherwise FALSE.
The default return value should therefore usually be FALSE (for all the stuff you don't handle). You override this for the stuff you do handle.
If you don't handle WM_CLOSE yourself, i.e. return FALSE in respose to a WM_CLOSE close message, then the dialog manager's message processing will handle it for you. If you return TRUE in response to WM_CLOSE you will stop the dialog manager from performing the default handling.
The default routine does not handle WM_DESTROY. I assume this is because quitting an app is belived to be something that should be under the control of the app writer.
#2
The WM_COMMAND is not just for menus. It's a message which allows you to send a command, which is used by the standard menus, (older) controls, and accelerator.
That is, while WM_COMMAND messages can come from a menu entry, they can also come from -- other -- controls (e.g. button, combobox, edit, static, ...) and accelerators. And there's nothing stopping you from sending custom WM_COMMAND messages internally if you want to.
The data sent with WM_COMMAND is a command ID (identifying the menu item, control, or accelertator entry) plus, in the case of a control, the control's window handle and a notification code (e.g. for a button BN_CLICK, BN_DBLCLK, ...; for an Edit control EN_CHANGE, EN_SETFOCUS, ...; ...).
(Instead of the notification code, message from menus contain a 0 and those from an acelerator, 1).
Andy
PPS The newer controls from comctl32.dll use WM_NOTIFY instead of WM_COMMAND. The notification message provides a more flexible way of passing data (instead of id, notification code, and hwnd, it uses structures (passed by address) which all use a standard header.
PS To quote MSDN directly:
From:
DialogProc callback function (Windows)
http://msdn.microsoft.com/en-gb/library/windows/desktop/ms645469%28v=vs.85%29.aspx
A dlgproc should return TRUE if it processes the message, otherwise FALSE.
The default return value should therefore usually be FALSE (for all the stuff you don't handle). You override this for the stuff you do handle.
If you don't handle WM_CLOSE yourself, i.e. return FALSE in respose to a WM_CLOSE close message, then the dialog manager's message processing will handle it for you. If you return TRUE in response to WM_CLOSE you will stop the dialog manager from performing the default handling.
The default routine does not handle WM_DESTROY. I assume this is because quitting an app is belived to be something that should be under the control of the app writer.
#2
The WM_COMMAND is not just for menus. It's a message which allows you to send a command, which is used by the standard menus, (older) controls, and accelerator.
That is, while WM_COMMAND messages can come from a menu entry, they can also come from -- other -- controls (e.g. button, combobox, edit, static, ...) and accelerators. And there's nothing stopping you from sending custom WM_COMMAND messages internally if you want to.
The data sent with WM_COMMAND is a command ID (identifying the menu item, control, or accelertator entry) plus, in the case of a control, the control's window handle and a notification code (e.g. for a button BN_CLICK, BN_DBLCLK, ...; for an Edit control EN_CHANGE, EN_SETFOCUS, ...; ...).
(Instead of the notification code, message from menus contain a 0 and those from an acelerator, 1).
Andy
PPS The newer controls from comctl32.dll use WM_NOTIFY instead of WM_COMMAND. The notification message provides a more flexible way of passing data (instead of id, notification code, and hwnd, it uses structures (passed by address) which all use a standard header.
PS To quote MSDN directly:
| Typically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message. |
From:
DialogProc callback function (Windows)
http://msdn.microsoft.com/en-gb/library/windows/desktop/ms645469%28v=vs.85%29.aspx
Last edited on
can you tell me what is "dialog box processed the message", is it like WinMain function, has a GetMessage() or something in it ?
Topic archived. No new replies allowed.