Comments

When an application starts, Windows gives it a unique number. In C++ this instance is stored in the HINSTANCE data type. This "instance" (which is also sometimes referred to as a "handle") can then be passed as a parameter to Windows API functions. For example if your application calls the function CreateWindow then you pass in the handle to your application so that Windows knows which application the window will belong to.

2. If we are talking about a [link=http://msdn.microsoft.com/en-us/library/ms633569(VS.85).aspx]window procedure[/link], then all messages go through that procedure and an application can either choose to process a message or to ignore it and pass it to the next procedure in the list (and may modify the message as well). The final window procedure is owned by Windows by default, so any message that isn't processed eventually gets passed to it for default processing (drawing the window for example). At least that's how I understand it.

[color=Blue]Pure Win32 API does not pass messages "down the road". MFC, probably does. Once you register a window class and message reaches the WndProc declared in that WNDCLASS structure - you can pass message to DefWindowProc() or to ignore it. However, some messages are processed by DefWindowProc() may be rerouted to system (WM_MOUSEWHEEL as an example) - that is possible.[/color]

Sure, but I was also considering the situation where a window is subclassed. If it is, then the message is passed on to the next handlers via CallWindowProc and the last user-defined procedure "on the road" passes it to DefWindowProc and the message is then handled by Windows.

I am very confused. I thought the process was as such:1. The application retrieves a message from the message queue.2. It translates, then dispatches the message back to Windows.3. Windows passes the message through the Windows Procedure to determine what it should do with the message. If the message is not contained within the switch statement, it is passed in DefWndProc.

You've understood it correctly. The point that I was trying to make was that there may be more than one window procedure handling the messages of a single window. In that case it is called subclassing and the procedures are called in a list where one calls the other. Sorry if it confused you..

Anyway, after successfully creating a window, there is usually a loop like this:[code] MSG msg; while (GetMessage(&msg, NULL, 0, 0) > 0) { TranslateMessage(&msg); DispatchMessage(&msg); }[/code]Step 1 is done by [link=http://msdn.microsoft.com/en-us/library/ms644936(VS.85).aspx]GetMessage[/link], it retrieves a message from the queue into the msg structure.

In step 2 [link=http://msdn.microsoft.com/en-us/library/ms644955(VS.85).aspx]TranslateMessage[/link] deals with simplifying keyboard input management. For example, normally when you press a key you get a "key down" and a "key up" message. TranslateMessage sees these messages and produces a new message with simply the key that was pressed.

Thanks for the clarification. I've also read that when the message is retrieved from the message queue, the application does some additional preprocessing to it before it is dispatched to Windows -- for example, "the application might call different functions in Windows to process specific kinds of messages."

[color=Blue]That's good, but sub-classing code is the responsibility of the programmer. If programmer will not pass the message to the original (before sub-classing) procedure - then message simply swallowed by application and system will not do anything automatically.[/color]

If I understand this correctly, you have 3 WindowProc during subclassing: the subclassed WindowProc (written by programmer), the original WindowProc (written by programmer) and the default WindowProc (default behavior handled by OS). Is that correct?