I too, at one point in time, had about the same problem you're asking now. I did'nt know which messages were sent first and that really obscured me from advancing further into the API.
One very good way to figure this out is to use a File Stream, and print the messages to a '.txt' file everytime your Window Procedure recieves a Message.
A simple basic app like the one below will print the following (omitting the exit messages):
As you can see, WM_CREATE is sent first. This is done when you call CreateWindow();. Then, WM_SETFOCUS is sent when you call ShowWindow(); and since the window is now visible on the screen, windows sends a WM_ERASEBKGND (to erase/paint the background with the specified background brush/color) message because the whole client area is INVALID. This is because the window was just created and nothing has yet been drawn/painted on it.
WM_ERASEBKGND message is followed by WM_SIZE. It is important that you know that WM_ERASEBKGND is usually sent before WM_SIZE and WM_PAINT. So saving the client dimensions to a static variable on WM_SIZE and using them in WM_ERASEBKGND will give you unwanted results, because, WM_SIZE has not yet been sent when you process the WM_ERASEBKGND.
Finally, WM_PAINT is sent. WM_PAINT is a low priority message, and because of this, this message is not processed untill all other messages in the message queue have been processed. Therefore, UpdateWindow is called right after ShowWindow. UpdateWindow causes the WM_PAINT message (If there's a WM_PAINT message in the message queue) to be sent IMMEDIATELY instead of untill all other messages have been processed.
Let me also emphasize that an application like this one, on a fairly decent computer, does'nt really need UpdateWindow() to be called right after ShowWindow() because today's computers can process Events lighting fast, and, you really would'nt see any delay in the client area being painted right after eraseing the client background in WM_ERASEBKGND. But, this is really not the case with more advanced, sophisticated appications, or games. An UpdateWindow() would almost certainly be crucial in this case to avoid the user see'ing a delay in painting.
I hope this has helped you. I don't know when WM_NCCREATE is sent as I have yet to deal with this particular message. But you can easily find this out with the technique I mentioned above =)
C and Win32 Code:
TCHAR *szWinName = TEXT("3Com");
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);
static int InitFile(void);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
TCHAR *szCmdLine, int iCmdShow)
static TCHAR szClassName = TEXT("3Com");
if ( !InitFile() )
wndclass.cbClsExtra = 0;
wndclass.cbWndExtra = 0;
wndclass.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wndclass.hInstance = hInstance;
wndclass.lpfnWndProc = WndProc;
wndclass.lpszClassName = szClassName;
wndclass.lpszMenuName = NULL;
wndclass.style = CS_HREDRAW | CS_VREDRAW;
if ( !RegisterClass(&wndclass) )
MessageBox(NULL, TEXT("This Program Requires Windows NT!"),
if ( !(hwnd = CreateWindow(szClassName,
MessageBox(NULL, TEXT("CreateWindow() Failed!"),
while ( GetMessage(&msg, NULL, 0, 0) )
LRESULT CALLBACK WndProc(HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
static int cxClient, cyClient;
static int cxChar, cxCaps, cyChar;
switch ( iMsg )
case WM_CREATE :
hdc = GetDC(hwnd);
cxChar = tm.tmAveCharWidth;
cxCaps = (tm.tmPitchAndFamily & 1 ? 3 : 2) * cxChar / 2;
cyChar = tm.tmHeight + tm.tmExternalLeading;
case WM_SETFOCUS :
case WM_ERASEBKGND :
hdc = GetDC(hwnd);
GetUpdateRect(hwnd, &updRect, FALSE);
case WM_SIZE :
cxClient = LOWORD(lParam);
cyClient = HIWORD(lParam);
case WM_PAINT :
hdc = BeginPaint(hwnd, &ps);
case WM_KILLFOCUS :
case WM_DESTROY :
return DefWindowProc(hwnd, iMsg, wParam, lParam);
static int InitFile(void)
if ( !(fp = fopen("C:\\Order of Messages.TXT", "a")) )
MessageBox(NULL, TEXT("InitFile Failed!"),
relient.[Edited by - xllx_relient_xllx on June 3, 2005 1:55:32 AM]
Understanding the Order-of-Messages in the Win32 API is Very important IMHO.