Hi. I have some questions. 1) Which is the message sent to the active window by pressing ALT-F4 ? (WM_QUIT ? WM_DESTROY ? or what ?) 2) Why WM_DESTROY is the only message that MUST be trapped in the simplest window procedure ? Who sends WM_DESTROY ? 3) When and why the window procedure should return zero in eax ? 4) I wrote a function in a DLL that subclasses the main window of the calling application. That function restores the original window function address before returning the control to the calling application. But I am experiencing every kind of faults. What should I care of ? Thanks from Alvise.
1) WM_CLOSE is sent to the window first. At this stage, the window can still choose whether to close itself or not. If it does, it must call DestroyWindow to destroy itself. Calling DestroyWindow causes WM_DESTROY message to be sent to your window. When the window receives WM_DESTROY, the window itself is already removed from the screen. 2) Because your main application enters a message loop which is an infinite loop. This loop polls the message queue to check for the messages destined for the windows in the application. Incidentally, this loop also prevents your app to return to Windows. You can exit the message loop when GetMessage returns FALSE. And GetMessage returns FALSE IF and ONLY IF it receives WM_QUIT. Now what causes WM_QUIT message to be sent to the application? Usually, it 's by some code in your own app that calls PostQuitMessage. PostQuitMessage places WM_QUIT in the message queue and returns. And we usually call PostQuitMessage when we receive WM_DESTROY message in the main window procedure. The rationale is that: when the MAIN window is closed, it is assumed that the application should exit to Windows as well. You need not process WM_DESTROY but somehow you must post WM_QUIT message when you want to terminate your app. And you usually want to terminate your app when your main window is destroyed. 3) You return zero in eax to indicate that the message sent to your window proc is already handled and Windows should not do its default handling on that message. It's a kind of an agreement between you, the coder, and Windows. If you are interested in some messages and want to handle them in your own window procedure, you return 0 in eax to tell Windows so. If you don't do that, Windows will never know whether the messages it sent to your proc is processed or not. It will have to do its default handling which is usually not what you want. If you don't handle some messages, you pass them to Windows by calling DefWindowProc. That way, Windows knows that it MUST handle them because your window proc does not. 4) You must at least preserve the values of edi, ebx registers in your window procedure. The easiest way is to save their values when your window proc is called and restore them when your proc is going to return.
1) Alt-F4 sends a WM_SYSCOMMAND message with an SC_CLOSE argument. Normally, this message is directed to DefWindowProc, which will respond by sending a WM_CLOSE message. You can intercept the WM_SYSCOMMAND message to disable the functions defined in the "system menu" that pops up when you click on the icon (in the upper left corner of the window). This message was edited by tank, on 2/2/2001 7:51:41 PM This message was edited by tank, on 2/2/2001 7:52:00 PM