<p>When an application is behind another applications and
I click on my application's taskbar icon, I expect the entire application to
come to the top of the z-order, even if an app-modal, WS_POPUP dialog box is
open.</p>

<p>However, some of the time, for some of my (and others') dialog boxes, only the dialog box comes to the front; the rest of the application stays behind.</p>

<p>I've looked at Spy++ and for the ones that work correctly, I can see
WM_WINDOWPOSCHANGING being sent to the dialog's parent. For the ones that
leave the rest of the application behind, WM_WINDOWPOSCHANGING is not being
sent to the dialog's parent.</p>

<p>I have an example where one dialog usually brings the whole app with it and the other does not. Both the working dialog box and the non-working dialog box have the same window style, substyle, parent, owner, ontogeny.</p>

<p>In short, both are WS_POPUPWINDOW windows created with DialogBoxParam(),
having passed in identical HWNDs as the third argument.</p>

<p>Has anyone else noticed this behavioral oddity in Windows programs? What messages does the TaskBar send to the application when I click its button? Who's responsibility is it to ensure that <em>all</em> of the application's windows come to the foreground?</p>

<p>In my case the base parentage is an MDI frame...does that factor in somehow?</p>

[{'answer_id': 51160, 'author': 'jmatthias', 'author_id': 2768, 'author_profile': 'https://Stackoverflow.com/users/2768', 'pm_score': 0, 'selected': False, 'text': "<p>Is the dialog's parent window set correctly?</p>\n\n<p>After I posted this, I started my own Windows Forms application and reproduced the problem you describe. I have two dialogs, one works correctly the other does not and I can't see any immediate reason is to why they behave differently. I'll update this post if I find out.</p>\n\n<p>Raymond Chen where are you!</p>\n"}, {'answer_id': 99547, 'author': 'jussij', 'author_id': 14738, 'author_profile': 'https://Stackoverflow.com/users/14738', 'pm_score': 1, 'selected': False, 'text': '<p>When you click on the taskbar icon Windows will send a <strong>WM_ACTIVATE</strong> message to your application.</p>\n\n<p>Are you sure your code is passing the <strong>WM_ACTIVATE</strong> message to the <strong>DefWindowProc</strong> window procedure for processing?</p>\n'}, {'answer_id': 1777881, 'author': 'P Daddy', 'author_id': 36388, 'author_profile': 'https://Stackoverflow.com/users/36388', 'pm_score': 3, 'selected': False, 'text': '<p>I know this is very old now, but I just stumbled across it, and I know the answer.</p>\n\n<p>In the applications you\'ve seen (and written) where bringing the dialog box to the foreground did <strong>not</strong> bring the main window up along with it, the developer has simply neglected to specify the owner of the dialog box.</p>\n\n<p>This applies to both modal windows, like dialog boxes and message boxes, as well as to modeless windows.  Setting the owner of a modeless popup also keeps the popup above its owner at all times.</p>\n\n<p>In the Win32 API, the functions to bring up a dialog box or a message box take the owner window as a parameter:</p>\n\n<pre><code>INT_PTR DialogBox(\n    HINSTANCE hInstance,\n    LPCTSTR lpTemplate,\n    HWND hWndParent,      /* this is the owner */\n    DLGPROC lpDialogFunc\n);\n\nint MessageBox(\n    HWND hWnd,            /* this is the owner */\n    LPCTSTR lpText,\n    LPCTSTR lpCaption,\n    UINT uType\n);\n</code></pre>\n\n<p>Similary, in .NET WinForms, the owner can be specified:</p>\n\n<pre><code>public DialogResult ShowDialog(\n    IWin32Window owner\n)\n\npublic static DialogResult Show(\n    IWin32Window owner,\n    string text\n) /* ...and other overloads that include this first parameter */\n</code></pre>\n\n<p>Additionally, in WinForms, it\'s easy to set the owner of a modeless window:</p>\n\n<pre><code>public void Show(\n    IWin32Window owner,\n)\n</code></pre>\n\n<p>or, equivalently:</p>\n\n<pre><code>form.Owner = this;\nform.Show();\n</code></pre>\n\n<p>In straight WinAPI code, the owner of a modeless window can be set when the window is created:</p>\n\n<pre><code>HWND CreateWindow(\n    LPCTSTR lpClassName,\n    LPCTSTR lpWindowName,\n    DWORD dwStyle,\n    int x,\n    int y,\n    int nWidth,\n    int nHeight,\n    HWND hWndParent, /* this is the owner if dwStyle does not contain WS_CHILD */\n    HMENU hMenu,\n    HINSTANCE hInstance,\n    LPVOID lpParam\n);\n</code></pre>\n\n<p>or afterwards:</p>\n\n<pre><code>SetWindowLong(hWndPopup, GWL_HWNDPARENT, (LONG)hWndOwner);\n</code></pre>\n\n<p>or (64-bit compatible)</p>\n\n<pre><code>SetWindowLongPtr(hWndPopup, GWLP_HWNDPARENT, (LONG_PTR)hWndOwner);\n</code></pre>\n\n<p>Note that MSDN has the following to say about <a href="http://msdn.microsoft.com/en-us/library/ms644898(VS.85).aspx" rel="noreferrer">SetWindowLong[Ptr]</a>:</p>\n\n<blockquote>\n  <p>Do not call <strong>SetWindowLongPtr</strong> with the GWLP_HWNDPARENT index to change the parent of a child window. Instead, use the <a href="http://msdn.microsoft.com/en-us/library/ms633541(VS.85).aspx" rel="noreferrer">SetParent</a> function. </p>\n</blockquote>\n\n<p>This is somewhat misleading, as it seems to imply that the last two snippets above are wrong.  This isn\'t so.  Calling <code>SetParent</code> will turn the intended popup into a <em>child</em> of the parent window (setting its <code>WS_CHILD</code> bit), rather than making it an owned window.  The code above is the correct way to make an existing popup an owned window.</p>\n'}]
['https://Stackoverflow.com/questions/51150', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/5309/']