Question

我从MSDN了解到windows如何处理发送到特定窗口的WM_PAINT消息。

MSDN似乎没有记录的一件事是窗口管理器决定哪些窗口应该接收WM_PAINT消息的实际过程，以及按什么顺序。

据我所知（通过阅读Raymond Chen和MSDN），没有与子窗口关联的无效区域 - 当子窗口无效时，父窗口上的相应区域将失效。

它的WM_PAINT生成让我感到困惑......以及windows无效区域被标记为有效的确切点（特别是wrt多线程） - 当涉及子窗口时，它变得特别有趣。 GetMessage如何确定哪一组窗口（父项+与无效区域相交的子窗口）获取WM_PAINT消息，以及按什么顺序？以及如何在WS_CLIPSIBLINGS，WS_CLIPCHILDREN，WS_EX_COMPOSITED，WS_EX_TRANSPARENT等方面进行更改？如果另一个线程在此过程中途使顶层窗口的一部分无效，会发生什么？

然后，在Windows V6.0 +上，DWM如何挂钩这个过程？

这是一个示例C程序，演示了使用WS_EX_COMPOSITED时出现的故障： -

#include <windows.h>
#include <windowsx.h>
INT delay = 50;
INT nPad = 32;

struct wnd_ctx {
  COLORREF base;
  char index;
};

HMODULE GetWindowModuleHandle(HWND hwnd){
  return (HMODULE)GetWindowLongPtr(hwnd,GWLP_HINSTANCE);
}

struct wnd_ctx* GetContext(HWND hWnd){
  struct wnd_ctx* pctx = (LPVOID)GetWindowLongPtr(hWnd,GWLP_USERDATA);
  if(!pctx)
  {
    pctx = malloc(sizeof(struct wnd_ctx));
    SetWindowLongPtr(hWnd,GWLP_USERDATA,(LONG_PTR)pctx);
  }
  return pctx;
}

LRESULT CALLBACK wnd_WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam){
  PAINTSTRUCT ps;
  HDC hdc;
  RECT rect;
  HBRUSH hbr;
  struct wnd_ctx* self;
  switch (message){
  case WM_LBUTTONUP:
    GetClientRect(hWnd,&rect);
    rect.top += nPad;
    rect.bottom -= nPad;
    rect.left += nPad;
    rect.right -= nPad;
    InvalidateRect(hWnd,&rect,TRUE);
    return 0;
  case WM_ERASEBKGND:
    DefWindowProc(hWnd, message, wParam, lParam);
    Sleep(delay);
    return 0;
  case WM_PAINT:
    hdc = BeginPaint(hWnd, &ps);
    if(self = GetContext(hWnd)){
      hbr = CreateSolidBrush(self->base + ((self->index++ <<5) & 0x7f));
      GetClientRect(hWnd,&rect);
      FillRect(hdc,&rect,hbr);
      DeleteObject(hbr);
    }
    EndPaint(hWnd, &ps);
    Sleep(delay);
    break;
  case WM_DESTROY:
    PostQuitMessage(0);
    break;
  default:
    return DefWindowProc(hWnd, message, wParam, lParam);
  }
  return 0;
}

ATOM CreateClass(HINSTANCE hInstance,LPCTSTR strClass,COLORREF brush,HICON hIcon){
  WNDCLASSEX wcex;
  wcex.cbSize = sizeof(WNDCLASSEX);
  wcex.style            = CS_HREDRAW|CS_VREDRAW;
  wcex.lpfnWndProc  = wnd_WndProc;
  wcex.cbClsExtra       = 0;
  wcex.cbWndExtra       = 0;
  wcex.hInstance        = hInstance;
  wcex.hIcon            = hIcon;
  wcex.hCursor      = LoadCursor(NULL, IDC_ARROW);
  wcex.hbrBackground    = CreateSolidBrush(brush);
  wcex.lpszMenuName = 0;
  wcex.lpszClassName    = strClass;
  wcex.hIconSm      = hIcon;
  return RegisterClassEx(&wcex);
}

BOOL CreateWindows(HINSTANCE hInstance, INT nCmdShow, LPCTSTR strTitle){
  HWND hWnd, hChild;
  ATOM atm;
  RECT rect;
  DWORD dwStyleEx, dwStyle, dwChildStyle, dwChildStyleEx;
  struct  wnd_ctx* pctx;
  dwStyleEx = WS_EX_COMPOSITED;
  dwStyle = WS_OVERLAPPEDWINDOW;//|WS_CLIPCHILDREN;
  dwChildStyle = WS_CHILD|WS_VISIBLE;//|WS_CLIPSIBLINGS;
  atm = CreateClass( hInstance, TEXT("APPWINDOW"), RGB(0x80,0x80,0x80), LoadIcon(NULL,IDI_APPLICATION));
  hWnd = CreateWindowEx(dwStyleEx,(LPCTSTR)atm, strTitle, dwStyle,
      CW_USEDEFAULT, 0, 256, 256, NULL, NULL, hInstance, NULL);
   pctx = GetContext(hWnd);
   pctx->base = RGB(0x00,0xff,0xff);
   pctx->index=0;
   atm = CreateClass(hInstance,TEXT("CONTROL1"),RGB(0x00,0x80,0x40),0);
   GetClientRect(hWnd,&rect);
   hChild = CreateWindowEx(0L,(LPCTSTR)atm, TEXT("Top"), dwChildStyle,
     rect.right/2, rect.top, rect.right/2, rect.bottom, hWnd, NULL, hInstance, NULL);
   pctx = GetContext(hChild);
   pctx->base = RGB(0x00,0xff,0x80);
   pctx->index=0;
   atm = CreateClass(hInstance,TEXT("CONTROL2"),RGB(0x00,0x40,0x80),0);
   hChild = CreateWindowEx(0L,(LPCTSTR)atm, TEXT("Bottom"), dwChildStyle,
     rect.left, rect.bottom/2, rect.right , rect.bottom/2, hWnd, NULL, hInstance, NULL);
   pctx = GetContext(hChild);
   pctx->base = RGB(0x00,0x80,0xff);
   pctx->index=0;
   ShowWindow(hWnd, nCmdShow);
   UpdateWindow(hWnd);
   return TRUE;
 }

int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPTSTR lpCmdLine,int nCmdShow){
  MSG msg;
  CreateWindows(hInstance,nCmdShow,TEXT("Test Child Painting"));
  while(GetMessage(&msg, NULL, 0, 0)>0){
    TranslateMessage(&msg);
    DispatchMessage(&msg);
  }
  return (int) msg.wParam;
}

Answer 1

传统的模型是没有人记住（因为内存很昂贵），因此每当窗口被覆盖时，内容都被遗忘，并且它被重新绘制以响应WM_PAINT。

但你知道这一点。

从应用程序的角度来看，DWM对此模型的主要改变不是绘画，而是无效，即导致需要绘画。当被其他窗口覆盖时，区域不一定（必然）无效，因为DWM会记住窗口的样子，因此不需要询问应用程序“提醒我想要再次在那里显示什么？”。

如果您自己显式或隐式地使区域无效（例如通过SetWindowText），那么它仍将获得WM_PAINT。

绘制父级时，可能会也可能不会剪切子项，具体取决于是否设置了子项。我相信绘画是从前到后完成的，允许子控件（例如）在自己的矩形之外绘制3D边框，就像在Microsoft Word 6中一样，如果你还记得那么远！

据我所知，这没有记录，因为你引用了Raymond Chen，你会知道他会提醒你不要依赖WM_PAINT消息的顺序。

儿童窗口绘画参考

1 个答案: