Which messages are processed by DefWindowProc?

StackOverflow https://stackoverflow.com/questions/2973919

  •  24-10-2019
  •  | 
  •  

Question

is there any documentation which messages are processed by DefWindowProc, and how?

I recently stumbled over WM_SETFONT/WM_GETFONT not being handled, I'm not sure if there's a mistake in my code, or if that's expected behavior, so I tried the following WinMain:

   WNDCLASSEX wcx =
   {
      sizeof(WNDCLASSEX),
      CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS, 
      DefWindowProc,
      0, 0,  // class/wnd extra bytes
      hInstance, 
      0,  
      LoadCursor(0, IDC_ARROW),
      0, 
      0,
      _T("some class"),
      0
   };

   ATOM a = RegisterClassEx(&wcx);
   _ASSERTE(a != 0);

   HWND wnd = CreateWindowEx(0, wcx.lpszClassName, NULL, 
                   WS_POPUP, 0,0,0,0, GetDesktopWindow(), 0, hInstance, 0);
   _ASSERTE(wnd != 0);

   HFONT font = (HFONT) GetStockObject(ANSI_VAR_FONT);
   _ASSERTE(font != 0);

   SendMessage(wnd, WM_SETFONT, (WPARAM) font, 0);
   HFONT font2 = (HFONT) SendMessage(wnd, WM_GETFONT, 0, 0);

   _ASSERTE(font2 == font);  // **FAILS**, font2 is 0
Was it helpful?

Solution

As far as I am aware - no. Each window message is a rare and unique thing that can differ in one of MANY ways. Some messages are expected to be posted, other's sent.

Some messages are notifications to the users window proc, others are commands to the DefXXXWindowProc handler(s) - DefWindowProc, DefDlgProc, DefMDIChildProc etc.

Some are handled the same in dialog and window procs, some must be handled differently.

WM_SETTEXT and WM_SETREDRAW are actually commands that DefWindowProc uses to modify internal data structures in the WND struct.

WM_SIZE is just a notification - sent BY DefWindowProc to its own window - in response to WM_WINDOWPOSCHANGED.

WM_MOUSExxx messages NEED to be posted, never sent, as windows frequently enter modal states where messages are read with GetMessage/PeekMessage and handled directly and NOT posted.

A lot of messages look like notifications, but MUST always be passed on to DefWindowProc because they're "secretly" used to implement the window manager. (WM_ACTIVATE and friends).

Most messages can be handled in a dialog proc by returning FALSE (or TRUE), some, with meaningful results need to use SetDlgResult, others are automatically handled (WM_CTLCOLOR*) as the dialog proc knows that a non zero result from the DialogProc corresponds to the LRESULT to return.

Some (WM_SYSCOMMAND) are not really messages to the window at all, and are just handled by DefWindowProc to do window manager type things (tile the desktop etc.)

There is no real attempt in the official documentation to categorize these differences.

To specifically address the WM_SET/GETFONT issue, WM_SETFONT, while a defined message, is not handled by DefwindowProc, and hence not handled by window classes that do not explicitly support it. Controls (EDIT, STATIC, etc) and Dialogs support WM_SETFONT and WM_GETFONT. To support it in a application registered class would require supplying an actual custom WindowProc and handling the message there.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top