{"id":43483,"date":"2014-12-03T07:00:00","date_gmt":"2014-12-03T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2014\/12\/03\/what-happens-if-i-dont-paint-when-i-get-a-wm_paint-message\/"},"modified":"2014-12-03T07:00:00","modified_gmt":"2014-12-03T07:00:00","slug":"what-happens-if-i-dont-paint-when-i-get-a-wm_paint-message","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20141203-00\/?p=43483","title":{"rendered":"What happens if I don't paint when I get a WM_PAINT message?"},"content":{"rendered":"

\nSuppose your window procedure doesn’t paint when it gets a\nWM_PAINT<\/code> message.\nWhat happens?\n<\/p>\n

\nIt depends on how you don’t paint.\n<\/p>\n

\nIf you have an explicit handler for the\nWM_PAINT<\/code> message\nthat does nothing but return without painting,\nthen the window manager will turn around and\nput a new\nWM_PAINT<\/code> message in your queue.\n“And try harder this time.”\nRemember that the rules for the\nWM_PAINT<\/code> message are that the window manager will\ngenerate a\nWM_PAINT<\/code> message\nfor any window that has a dirty region.\nIf you fail to remove the dirty region in your\nWM_PAINT<\/code> message handler,\nwell, then the rules state that you get another\nWM_PAINT<\/code> message.\n(The most common way of clearing the dirty region is to call\nBegin­Paint<\/code>,\nbut there are other less common ways,\nlike\nValidate­Rect<\/code> or\nRedraw­Window<\/code> with the RDW_VALIDATE<\/code> flag.)\n<\/p>\n

\nThe other case is that you\nsimply don’t have a WM_PAINT<\/code> handler\nand let the message fall through to\nDef­Window­Proc<\/code>.\nIn that case,\nDef­Window­Proc<\/code>\nwill do a blank paint for you.\nIn other words,\nDef­Window­Proc<\/code> contains\nthe logical equivalent of\n<\/p>\n

\ncase WM_PAINT:\n {\n  PAINTSTRUCT ps;\n  if (BeginPaint(hwnd, &ps))\n   EndPaint(hwnd, &ps);\n }\n return 0;\n<\/pre>\n
\nIn the case where you pass the\nWM_PAINT<\/code> to\nDef­Window­Proc<\/code>,\nthe dirty region is cleared because\nDef­Window­Proc<\/code>\nwill call\nBegin­Paint<\/code> for you.\n<\/p>\n
\nThere are some quirks in the handling of the\nWM_PAINT<\/code> message by the\nDef­Window­Proc<\/code> function\nto handle various application compatibility cases,\nbut the above is the basic idea.\n<\/p>\n
\nTo avoid tripping over the weird application compatibility\ncases, decide up front how you want to deal with\nWM_PAINT<\/code> messages delivered to your window\nprocedure.\n<\/p>\n
    \n
  • Handle them completely\n    by calling\n    Begin­Paint<\/code> and\n    End­Paint<\/code>,\n    then returning 0.\n    (Do not pass the message to\n    Def­Window­Proc<\/code>.)<\/p>\n
  • Pass them all to\n    Def­Window­Proc<\/code>,\n    and let it do the\n    Begin­Paint<\/code> and\n    End­Paint<\/code>.\n<\/ul>\n
    \nDon’t try playing fancy games like\n“Oh, I’m going to call\nBegin­Paint<\/code> and\nEnd­Paint<\/code>,\nbut sometimes I’m also<\/i> going to pass the message to\nDef­Window­Proc<\/code> afterwards.”\nJust pick one plan and stick to it.\nIt’s a lot simpler for everybody that way.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Suppose your window procedure doesn’t paint when it gets a WM_PAINT message. What happens? It depends on how you don’t paint. If you have an explicit handler for the WM_PAINT message that does nothing but return without painting, then the window manager will turn around and put a new WM_PAINT message in your queue. “And […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-43483","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
    Suppose your window procedure doesn’t paint when it gets a WM_PAINT message. What happens? It depends on how you don’t paint. If you have an explicit handler for the WM_PAINT message that does nothing but return without painting, then the window manager will turn around and put a new WM_PAINT message in your queue. “And […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/43483","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=43483"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/43483\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=43483"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=43483"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=43483"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}