Какие сообщения обрабатываются DefWindowProc?

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

  •  24-10-2019
  •  | 
  •  

Вопрос

Существует ли какая -либо документация, какие сообщения обрабатываются DefWindowProc, и как?

Недавно я наткнулся на WM_SETFONT/WM_GETFONT, который не обрабатывался, я не уверен, есть ли ошибка в моем коде, или это ожидаемое поведение, поэтому я попробовал следующий 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
Это было полезно?

Решение

Насколько мне известно - нет. Каждое оконное сообщение - редкая и уникальная вещь, которая может отличаться во многих отношениях. Ожидается, что некоторые сообщения будут опубликованы, другие отправлены.

Некоторые сообщения являются уведомлениями для окна пользователей, другие являются командами для обработчика (ы) defxxxwindowproc - defwindowproc, defdlgproc, defmdichildproc и т. Д.

Некоторые обрабатываются одинаково в диалоговом окне и оконных проведениях, некоторые должны обрабатывать по -разному.

WM_Settext и WM_SetredRaw на самом деле являются командами, которые DefWindowProc использует для изменения внутренних структур данных в wnd struct.

WM_SIZE - это просто уведомление - отправлено DefWindowProc в свое собственное окно - в ответ на WM_WINDOWPOSCHANGED.

Сообщения WM_MOUSEXXX должны быть опубликованы, никогда не отправляемые, так как Windows часто вводит модальные состояния, где сообщения читаются с GetMessage/PeekMessage и обрабатываются напрямую и не публикуются.

Много сообщений Смотреть Как уведомления, но всегда должны быть переданы DefWindowProc, потому что они «тайно» используются для реализации менеджера Window. (Wm_activate и друзья).

Большинство сообщений можно обрабатывать в диалоговом окне, возвращая false (или true), некоторые, с значимыми результатами, необходимо использовать SetDlgResult, другие обрабатываются автоматически (wm_ctlcolor*) в качестве диалога Proc знает что не нулевой результат от DialogProc соответствует LRESULT для возврата.

Некоторые (wm_syscommand) на самом деле не являются сообщениями в окно вообще, и только что обрабатываются Defwindowproc, чтобы сделать тип менеджера окна (Tile the Desktop и т. Д.)

В официальной документации нет реальной попытки классифицировать эти различия.

Специально решать WM_SET/GETFONT проблема, WM_SETFONT, в то время как определенное сообщение не обрабатывается DefWindowProc и, следовательно, не обрабатывается классами окон, которые явно не поддерживают его. Управление (редактирование, статика и т. Д.) И поддержка диалогов WM_SETFONT а также WM_GETFONT. Анкет Чтобы поддержать его в приложении, зарегистрированном классе, потребует поставки фактического пользовательского WindowProc и обработки сообщения там.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top