Windows API: What is the first message a window is guaranteed to receive?

Question

I've been used to thinking that WM_CREATE is the first message a window receives. However, when testing this assumption on a top-level window, it turns out to be false. In my test, WM_MINMAXINFO turned up as the first message.

So, what is the first message a window is guaranteed to receive?

Answer 1

WM_NCCREATE is actually the very first message your window will receive, which will arrive before WM_CREATE. It is related to creating the non-client area (eg. title bar, system menu, etc), hence the NC prefix.

WM_GETMINMAXINFO is sent before the window size/position is changed, and may arrive before WM_CREATE (see below for more).

The WM_CREATE message is sent before CreateWindow() returns, so you can guarantee that per-window initialisation has been performed by that point. Your window proc will receive WM_CREATE after the window is created, but before the window becomes visible (WM_SHOWWINDOW).

Actually, there is an interesting inconsistency in the MSDN documentation - the creation messages seem to depend on whether you call CreateWindow() or CreateWindowEx(), however it does not specify that the messages are necessarily listed in order of dispatching.

• CreateWindow(): WM_CREATE, WM_GETMINMAXINFO and WM_NCCREATE
• CreateWindowEx(): WM_NCCREATE, WM_NCCALCSIZE, and WM_CREATE

I strongly suspect that the message order described in CreateWindow() should have WM_NCCREATE first, and the regular WM_CREATE last, which is consistent with the notification documentation and the CreateWindowEx() reference (and also consistent with what you describe).

Raymond Chen also has some interesting information on window creation/destruction.

It just goes to show, even seemingly simple things can get complex the more you look at them.

Answer 2

You can use spy++ which comes with visual studio to see what messages are generated when the application or window is started.

Answer 3

You answered your own question. I too see WM_GETMINMAXINFO, on Windows XP SP3, followed by WM_NCCREATE, WM_NCCALCSIZE, and finally WM_CREATE before CreateWindowEx() has even returned the handle to the window being created. What garabage'

The general answer is that Microsoft is incompetent when it comes to orderly creation and destruction of objects. They get it wrong with windows, with COM, and with device drivers. There's always some catch-22 where an object is half-created or half-destroyed that requires some roundabout convoluted solution to produce a reliable product.