No, really, you need to pass all unhandled messages to DefWindowProc

Raymond Chen

Earlier I had discussed that you have to return the special value BROADCAST_QUERY_DENY if you want to deny a device removal query because too many programs thought that they had covered “all” the Windows messages and just returned zero for the others. Since then, there have been lots of other window messages added to the system, many of which contain nontrivial processing in DefWindowProc. Yet, every so often, I run into another program that assumed that “Microsoft will never enhance the window manager” and simply returned zero for all the messages they didn’t handle. Indeed, often these programs don’t even cover all the existing messages! One program had a helper window that handled just a few messages and returned zero for the rest. As a result, you couldn’t shut down the computer because returning zero in response to the WM_QUERYENDSESSION message means, “No, don’t shut down.” I guess the people who wrote that program assumed you would shut down their program manually. (Programs are not supposed to fail a shutdown unless the decision came from the user, typically by clicking “Cancel” in response to a “Do you want to exit without saving?”) Custom keyboard buttons like the volume control buttons didn’t work either (if focus was on this helper window), because it neglected to pass the WM_APPCOMMAND message to the DefWindowProc function. Therefore, once again, I implore you: If you don’t handle a message in your window procedure, pass it to the DefWindowProc function. Your customer base thanks you.

(Note for people who take what I say too literally: If you are using a framework, then follow that framework’s protocol for indicating that you want default message processing to occur. For example, dialog procedures do not pass unhandled messages to the DefWindowProc function; they merely return FALSE to indicate that default processing should take place.)

Raymond Chen

Follow