{"id":29603,"date":"2006-09-25T10:00:02","date_gmt":"2006-09-25T10:00:02","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2006\/09\/25\/waiting-until-the-dialog-box-is-displayed-before-doing-something\/"},"modified":"2006-09-25T10:00:02","modified_gmt":"2006-09-25T10:00:02","slug":"waiting-until-the-dialog-box-is-displayed-before-doing-something","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20060925-02\/?p=29603","title":{"rendered":"Waiting until the dialog box is displayed before doing something"},"content":{"rendered":"

\nLast time,\n\nI left you with a few questions<\/a>.\n\nPart of the answer to the first question\nwas given in the comments<\/a>, so I’ll just link to that.\nThe problem is more than just typeahead, though.\nThe dialog box doesn’t show itself until all message traffic\nhas gone idle.\nIf you actually ran the code presented in the original message,\nyou’d find that it didn’t actually work!\n<\/p>\n

\n#include <windows.h>\nINT_PTR CALLBACK\nDlgProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)\n{\n  switch (uiMsg) {\n  case WM_INITDIALOG:\n    PostMessage(hwnd, WM_APP, 0, 0);\n    return TRUE;\n  case WM_APP:\n    MessageBox(hwnd,\n              IsWindowVisible(hwnd) ? TEXT(\"Visible\")\n                                    : TEXT(\"Not Visible\"),\n               TEXT(\"Title\"), MB_OK);\n    break;\n  case WM_CLOSE:\n   EndDialog(hwnd, 0);\n   break;\n  }\n  return FALSE;\n}\nint WINAPI WinMain(HINSTANCE hinst, HINSTANCE hinstPrev,\n                   LPSTR lpCmdLine, int nShowCmd)\n{\n    DialogBox(hinst, MAKEINTRESOURCE(1), NULL, DlgProc);\n    return 0;\n}\n<\/pre>\n
\nWhen you run this program, the  message box says “Not Visible”,\nand in fact when it appears, you can see that the main dialog\nis not yet visible.\nIt doesn’t show up until after you dismiss the message box.\n<\/p>\n
\nMission: Not accomplished.\n<\/p>\n
\nAlong the way, there was some dispute over whether the\nprivate message should be WM_USER<\/code> or\nWM_APP<\/code>.\nAs we saw before,\n\nwindow messages in the WM_USER<\/code> range belong to the\nwindow class<\/a>,\nand in this case, the window class is the dialog window class,\ni.e.<\/i>, WC_DIALOG<\/code>.\nSince you are not the implementor of the dialog window class\n(you didn’t write the window procedure),\nthe WM_USER<\/code> messages are not yours for the taking.\nAnd in fact, if you had decided to use WM_USER<\/code>\nyou would have run into all sorts of problems,\nbecause it so happens that the dialog manager\nalready defined that message for its own purposes:\n<\/p>\n
\n#define DM_GETDEFID         (WM_USER+0)\n<\/pre>\n
\nWhen the dialog manager sends the dialog a DM_GETDEFID<\/code>\nmessage to obtain the default control ID,\nyou will think it’s your WM_USER<\/code> message and show your\ndialog box.\nIt turns out that the dialog manager uses the default control ID\nrather often, and as a result, you’re going to display an awful\nlot of dialog boxes.\n(Even worse, your second dialog box will probably use the dialog\nitself as the owner, which then leads to the problem of\nhaving a dialog box with multiple modal children<\/a>,\n\nwhich then leads to disaster when they are dismissed by the\nuser in the wrong order<\/a>.)\n<\/p>\n
\nOkay, so we’re agreed that we should use WM_APP<\/code>\nas the private message.\n<\/p>\n
\nSome people suggested using a timer,\non the theory that timer messages are lower priority than\npaint messages,\nso the timer won’t fire until all painting is done.\nWhile that’s true, it also doesn’t help.\nThe relative priority of timer and paint messages comes\ninto play only if the window manager has to choose between\ntimers and paint messages when deciding which one to deliver\nfirst.\nBut if there are no paint messages needed in the first place,\nthen timers are free to go ahead.\n<\/p>\n
\nAnd when the window is not visible,\nit doesn’t need any paint messages.\nIn a sense, the timer approach misses the point entirely:\nIt’s trying to take advantage of paint messages being higher priority\nprecisely in the scenario where there are no paint messages!\n<\/p>\n
\nLet’s demonstrate this by implementing the timer approach,\nbut I’m going to add a twist to make the race condition clearer:\n<\/p>\n
\n...\nINT_PTR CALLBACK\nDlgProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)\n{\n  switch (uiMsg) {\n  case WM_INITDIALOG:\n    SetTimer(hwnd, 1, 1, 0);\n    Sleep(100); \/\/simulate paging\n    return TRUE;\n  case WM_TIMER:\n    if (wParam == 1) {\n      KillTimer(hwnd, 1);\n      MessageBox(hwnd,\n                IsWindowVisible(hwnd) ? TEXT(\"Visible\")\n                                      : TEXT(\"Not Visible\"),\n                 TEXT(\"Title\"), MB_OK);\n    }\n    break;\n  case WM_CLOSE:\n   EndDialog(hwnd, 0);\n   break;\n  }\n  return FALSE;\n}\n<\/pre>\n
\nIf you run this program, you’ll see the message “Not Visible”.\nI inserted an artificial Sleep(100)<\/code> to simulate\nthe case where the code takes a page fault and has to wait\n100ms for the code to arrive from the backing store.\n(Maybe it’s coming from the network or a CD-ROM,\nor maybe the local hard drive is swamped with I\/O and\nyou have to wait that long for your paging request to\nbecome satisfied after all the other I\/O requests active\non the drive.)\n<\/p>\n
\nAs a result of that Sleep()<\/code>,\nthe dialog manager doesn’t get a chance to empty the message\nqueue and show the window because the timer message is already\nin the queue.\nResult: The timer fires and the dialog is still hidden.\n<\/p>\n
\nSome people waited for WM_ACTIVATE<\/code>, but that\ntells you when the window becomes active, which is not the\nsame as being shown, so it doesn’t satisfy the original\nrequirements.\n<\/p>\n
\nOthers suggested waiting for WM_PAINT<\/code>,\nbut a window can be visible without painting.\nThe WM_PAINT<\/code> message arrives if the window’s\nclient area is uncovered, but the caption bar might still be\nvisible even if the client area is covered.\nFurthermore, while this addresses the problem if you interpret\n“visible” as “results in pixels on the screen”,\nas opposed to IsWindowVisible<\/code>,\nyou need to look behind the actual request to what the person\nwas really looking for.\n(This is an important skill to have because people rarely ask\nfor what they want, but rather for what they think they want.)\nThe goal was to create a dialog box and have it look like the\nuser automatically clicked a button on it to call up a secondary dialog.\nIn order to get this look, the base dialog needs to be visible\nbefore the secondary dialog can be displayed.\n<\/p>\n
\nOne approach is to show the second dialog on receipt of the\nWM_SHOWWINDOW<\/code>, but even that is too soon:\n<\/p>\n
\n\/\/ In real life, this would be an instance variable\nBOOL g_fShown = FALSE;\nINT_PTR CALLBACK\nDlgProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)\n{\n  switch (uiMsg) {\n  case WM_INITDIALOG:\n    return TRUE;\n  case WM_SHOWWINDOW:\n    if (wParam && !g_fShown) {\n      g_fShown = TRUE;\n      MessageBox(hwnd,\n                 IsWindowVisible(hwnd) ? TEXT(\"Visible\")\n                                       : TEXT(\"Not Visible\"),\n                 TEXT(\"Title\"), MB_OK);\n    }\n    break;\n  case WM_CLOSE:\n   EndDialog(hwnd, 0);\n   break;\n  }\n  return FALSE;\n}\n<\/pre>\n
\n(Subtlety: Why do I set g_fShown = TRUE<\/code> before\ndisplaying the message box?)\n<\/p>\n
\nIf you run this program, you will still get the message\n“Not Visible” because WM_SHOWWINDOW<\/code> is sent\nas part of the entire window-showing process.\nAt the time you receive it, your window is in the\nprocess of being show<\/strong> but it’s not quite there yet.\nThe WM_SHOWWINDOW<\/code> serves a similar purpose\nto WM_INITDIALOG<\/code>: To let you prepare the window\nwhile it’s still hidden so the user won’t see ugly flashing\nwhich would otherwise occur if you had done\nyour preparation after the window were visible.\n<\/p>\n
\nIs there a message that is sent after the window has been shown?\nThere sure is: WM_WINDOWPOSCHANGED<\/code>.\n<\/p>\n
\nINT_PTR CALLBACK\nDlgProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)\n{\n  switch (uiMsg) {\n  case WM_INITDIALOG:\n    return TRUE;\n  case WM_WINDOWPOSCHANGED:\n    if ((((WINDOWPOS*)lParam)->flags & SWP_SHOWWINDOW) &&\n        !g_fShown) {\n      g_fShown = TRUE;\n      MessageBox(hwnd,\n                 IsWindowVisible(hwnd) ? TEXT(\"Visible\")\n                                       : TEXT(\"Not Visible\"),\n                 TEXT(\"Title\"), MB_OK);\n    }\n    break;\n  case WM_CLOSE:\n   EndDialog(hwnd, 0);\n   break;\n  }\n  return FALSE;\n}\n<\/pre>\n
\nThis time, we get the message “Visible”,\nbecause WM_WINDOWPOSCHANGED<\/code> is sent after\nthe window positioning negotiations are complete.\n(The “ED” at the end emphasizes that it is delivered\nafter the operation has been done, as opposed to the “ING”\nwhich is delivered while the operation is in progress.)\n<\/p>\n
\nBut wait, we’re not out of the woods yet.\nAlthough it’s true that the window position negotiations\nare complete, the message is nevertheless sent as part\nof the whole window positioning process,\nand there may be other things that need to be done\nas part of the whole window-showing bookkeeping.\nIf you show the second dialog directly in your\nWM_WINDOWPOSCHANGED<\/code> handler,\nthen that clean-up won’t happen until after the user\nexits the second dialog.\n<\/p>\n
\nFor example, the window manager notifies Active Accessibility\nof the completed window positioning operation after all\nthe window positions have settled down.\nThis reduces the likelihood that the accessibility tool will be told\n“Okay, the window is shown” followed by\n“Oh no wait, it moved again, ha ha!”\nIf you display the second dialog inside your\nWM_WINDOWPOSCHANGED<\/code> handler,\nthe screen reader will receive a bizarro sequence of events:\n<\/p>\n
    \n
  • Second dialog shown.\n
  • (User interacts with second dialog and dismisses it.)\n
  • Second dialog destroyed.\n
  • (Your WM_WINDOWPOSCHANGED<\/code> handler returns.)\n
  • Main dialog shown.\n<\/ul>\n
    \nNotice that the “Main dialog shown” notification arrives out of\norder because you did additional UI work before the previous operation\nwas complete.\n<\/p>\n
    \nAs another example, the window may have been shown as part\nof a multiple-window window positioning operation\nsuch as one created by DeferWindowPos<\/code>.\nAll the affected windows will get their WM_WINDOWPOSCHANGED<\/code>\nnotifications one at a time,\nand if your window happened to go first,\nthen those other windows won’t know that they were repositioned\nuntil after the user finishes with the nested dialog.\nThis may manifest itself in those other windows appearing to\nbe “stuck” since your dialog is holding up the subsequent\nnotifications with your nested dialog.\nFor example, a window might be trying to do\nexactly what you’re trying to do here<\/strong>,\nbut since you’re holding up the remainder of the notifications,\nthat other window won’t display its secondary dialog until\nthe user dismisses yours.\nFrom the user’s standpoint, that other window is “stuck”\nfor no apparent reason.\n<\/p>\n
    \nTherefore, we need one more tweak to our solution.\n<\/p>\n
    \nINT_PTR CALLBACK\nDlgProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)\n{\n  switch (uiMsg) {\n  case WM_INITDIALOG:\n    return TRUE;\n  case WM_WINDOWPOSCHANGED:\n    if ((((WINDOWPOS*)lParam)->flags & SWP_SHOWWINDOW) &&\n        !g_fShown) {\n      g_fShown = TRUE;\n      PostMessage(hwnd, WM_APP, 0, 0);\n    }\n    break;\n  case WM_APP:\n      MessageBox(hwnd,\n                 IsWindowVisible(hwnd) ? TEXT(\"Visible\")\n                                       : TEXT(\"Not Visible\"),\n                 TEXT(\"Title\"), MB_OK);\n      break;\n  case WM_CLOSE:\n   EndDialog(hwnd, 0);\n   break;\n  }\n  return FALSE;\n}\n<\/pre>\n
    \nWhen we learn that the dialog is being shown for the first time,\nwe post a message to ourselves to display the secondary dialog\nand return from the WM_WINDOWPOSCHANGED<\/code> handler.\nThis allows the window positioning operation to complete.\nEverybody gets their notifications, they are all on board\nwith the state of the windows,\nand only after everything has stabilized do we display our\nmessage box.\n<\/p>\n
    \nThis is a common thread to many types of window management.\nMany window messages are notifications which are delivered\nwhile the operation is still in progress<\/strong>.\nYou do not want to display new UI while handling those\nnotifications because that holds up the completion of the\noriginal UI operation that generated the notification in the\nfirst place.\nPosting a message to yourself to complete the user interaction\nafter the original operation has stabilized is the standard solution.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Last time, I left you with a few questions. Part of the answer to the first question was given in the comments, so I’ll just link to that. The problem is more than just typeahead, though. The dialog box doesn’t show itself until all message traffic has gone idle. If you actually ran the code […]<\/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-29603","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
    Last time, I left you with a few questions. Part of the answer to the first question was given in the comments, so I’ll just link to that. The problem is more than just typeahead, though. The dialog box doesn’t show itself until all message traffic has gone idle. If you actually ran the code […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/29603","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=29603"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/29603\/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=29603"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=29603"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=29603"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}