I'm a bit confused currently: Are WM_CLOSE and ::CloseWindow in any way "related" or are for completely different things?
The docs for Closing Windows don't mention the API function CloseWindow at all. Should CloseWindow be really called "MinimizeWindow" or what am I missing?
CloseWindow and WM_CLOSE are completely unrelated. The CloseWindow function is badly named. Its inverse function, OpenWindow is similarly badly named given that it restores windows.
I suspect these names dates back a very long way indeed, probably to Windows version 1 or 2. I'm speculating that what we now call minimize and restore were, back then, called close and open.
The usual way to minimize or restore a window is to call ShowWindow passing SW_MINIMIZE or SW_RESTORE.
I suggest that you forget all about CloseWindow and OpenWindow.
CloseWindow is an unusually poorly named winapi function. It doesn't actually close a window, it just minimizes it. What you possibly meant was DestroyWindow().
WM_CLOSE is normally a message that's generated by default window procedure, in response to the user pressing Alt+F4 or clicking the window's close button. The underlying message is WM_SYSCOMMAND, SC_CLOSE. It can be generated in code as well, like a Window + Close menu item.
You can listen for WM_CLOSE in your window procedure or the MFC message map. The user will expect the window to be closed. So you normally call DestroyWindow(). You don't have to, you might display a message box for example and ask the user if data should be saved. And if he clicks No then you don't call DestroyWindow().
I would say ignore CloseWindow and OpenWindow() for the reasons the previous poster suggested. However, while technically doable, it is considered bad form to handle whether to save or actually destroy a window (ie prompting the user) during WM_DESTROY. Once DestroyWindow is called and the OS sends a WM_DESTROY message, the expectation is to prepare for the destruction of the window. So the workflow should have be like this:
Send a WM_CLOSE to the window handle in question. CloseWindow SHOULD do this, like DestroyWindow sends a WM_DESTROY message or ShowWindow sends a WM_SHOWWINDOW message. But again, since it doesn't, send the WM_CLOSE to the window.
Next, during the processing of the WM_CLOSE message, you can ask the user if they wish to save anything, or if they intend to actually close the window. If they cancel closing the window, simply return ZERO to tell the OS you processed the message. If the user indicates they wish to proceed, THEN you can call DestroyWindow OR simply pass the message to DefWindowProc, which the promptly do the same. Any saving of files should happen during the processing of WM_CLOSE. During the processing of WM_DESTROY, you should delete any dynamically allocated memory associated with the window and free resources. And finally FYI, WM_NCDESTROY is the last message a window receives.
Related
I have a fairly simple windows program that created a listview control that should exactly fill the client area. That works at start up, and I think will work if the window is resized --- except the windows NEVER receives any WM_SIZE messages (after the initial one sent on window creation.) I verified this using Spy++x64 as an administrator to ensure I was capturing everything. Spy++ showed the window receiving WM_SIZING, WM_WINPOSCHANGED, WM_NCCALCSIZE, and WM_WINPOSCHANGING (this list isn't in any particular order) but NEVER a WM_SIZE.
This is a 64-bit program, but I don't know why that should matter.
So, is there something I could have done that allows the window to be completely resizable, but prevent Windows from ever generating WM_SIZE messages when that happens? If not, is there something I need to do (that was never needed in the past 30 years) to let Windows know I need to see those WM_SIZE events?
It turns out that the default window procedure generates the WM_SIZE when it processed WM_WINDOWPOSCHANGED and, since I was handling WM_WINDOWPOSCHANGED, no size messages were created. So I forwarded the position changed message to the default handler and the messages are back.
This follows documented behavior. There's a remark in the documentation for the WM_WINDOWPOSCHANGED documentation:
By default, the DefWindowProc function sends the WM_SIZE and WM_MOVE messages to the window. The WM_SIZE and WM_MOVE messages are not sent if an application handles the WM_WINDOWPOSCHANGED message without calling DefWindowProc. It is more efficient to perform any move or size change processing during the WM_WINDOWPOSCHANGED message without calling DefWindowProc.
Yup, I'm sorry to admit that I failed to read the documentation for all of the Window messages that I was NOT having problems with when I needed to find out about WM_SIZE. Silly me for not assuming the documentation I needed about WM_SIZE was only to be found under some other message! All it says about the message generation in the WM_SIZE documentation is:
Sent to a window after its size has changed.
There is no mention AT ALL of any dependency on the default processing for a DIFFERENT message to be found. Ergo, the behavior is effectively undocumented, especially since it may be critical information, as it was for me.
Oh well, I give up, this place has become far too much of just smacking people down for asking questions some people think are too easily answered. Try to remember that not everyone has an eidetic memory and access to all of the documentation you have all memorized. Some of us look up the thing we're working on and expect to find the important details about it. THEY ARE NOT PRESENT. Bye!
My goal is to disable some tool-tip-like thing in window of another process. My thoughts are to block WM_MOUSEMOVE if the coordinates of mouse movement is in certain rectangle of the window.
I can use SetWindowsHookEx to receive that messages (WH_CALLWNDPROC and WH_GETMESSAGE), but it doesn't allow to block them. I can return 1 instead of calling CallNextHookEx, but it doesn't prevent WndProc of window to receive the message. However, this approach works for blocking events in MOUSE_LL/KEYBOARD_LL.
SetWindowsHookEx is also not good, because it installs hook to all windows across the system.
How I can prevent window of another process from receiving certain windows messages?
The WH_GETMESSAGE message hook doesn't let you "block" or cancel the message but you can modify it. So simply change lpMsg->message to WM_NULL to prevent the mouse move message from being processed by the target window.
When I create a dialog using DialogBox, it won't close unless I handle WM_CLOSE in my own DLGPROC function and call EndDialog.
I know that this is by design, but I'm interested why was it chosen for WM_CLOSE not to be handled automatically by DefDlgProc? Are there any good reasons for that?
Ask yourself this:
What would the default handling of WM_CLOSE be? Calling EndDialog? I think EndDialog would only work in very rare situations.
Other suggestions:
validating user input in the dialog, showing errors if input is out-of-range or otherwise not valid, not ending the dialog
closing child windows, releasing resources/memory that child windows of the dialog are using, releasing COM-Objects, basically: cleaning up first and then end the dialog.
ShowWindow(g_hWnd, 1);
UpdateWindow(g_hWnd);
I am wondering why we need to call UpdateWindow following the ShowWindow?
It is entirely unnecessary, your window will paint just fine without it.
You'll see a minor benefit from it if your program goes off doing lots of stuff after creating the window but before entering the message loop. The user has something to look at. A splash screen is the more typical approach.
ShowWindow does not repaint the window. The call to UpdateWindow sends WM_PAINT message to the window and thus repainting it.
Normally, the system sends WM_PAINT only if the message queue is empty. Under normal circumstances this is good enough and it actually optimizes out a lot of unnecessary repaint. The messages in the queue often will change application state which can often result in invalidating part of the window, and hence result in yet another painting (so the user sees the new application state). So the repaint just happens after all such messages are handled and the system thinks the new window content will be valid for some time (until yet another message(s) come into the queue).
However if you need to force the WM_PAINT immediately and bypass the logic above, you may force sending WM_PAINT (if there is an invalid region) by calling UpdateWindow().
ShowWindow causes a WM_PAINT message, whereas anything which makes a previously hidden part of a window visible. UpdateWindow does any outstanding paint message(s) to be delivered immediately, waiting until the paint processing is complete until returning. Without the call to UpdateWindow the message isn't received until your program goes into the message loop. This avoids any possible delay in response to the user.
When a modal dialog box is present, messages sent to the main window using PostMessage do not go through that window's message loop. In fact, no message go through the main window's message loop while the modal dialog is present. They do make it to the main window's WndProc presumably through some message loop in the dialog handling.
Is this normal or am I doing something bizarre?
This is normal, the dialog box becomes modal by pumping its own message loop. This should not be a problem, DispatchMessage still delivers the message to the window procedure. Make sure you post with a valid window handle. Otherwise also the reason that PostThreadMessage() is a guaranteed fail whale if the thread creates any windows. Like MessageBox().