title: How does Windows's "Safely Remove Hardware" dialog get the "foreground love"?
body: <p><a href="http://blogs.msdn.com/b/oldnewthing/archive/2009/02/26/9445006.aspx" rel="noreferrer">Raymond has blogged about</a> how programs can get/steal the &quot;foreground love&quot; by using <code>RegisterHotkey</code>, which, when invoked, will transfer the foreground-ness to your application.</p>
  <p>Attempts to do this manually fail miserably (e.g. using <code>SetForegroundWindow</code>, <code>SwitchToWindow</code>, etc.), because applications must not be able to steal the focus from a user (so that keypresses don't go to the wrong place).</p>
  <p>The trouble is, today I noticed something weird:</p>
  <ol>
  <li><p>I try to Safely Remove an external drive.</p>
  </li>
  <li><p>There is a ~7-second pause.</p>
  </li>
  <li><p><em>During the pause</em>, I am vigorously typing inside a window.</p>
  </li>
  <li><p>Suddenly, a message box <em>steals</em> the foreground-ness from my app, and my typing goes into the message box instead.</p>
  </li>
  </ol>
  <p>Clearly, this isn't using a hotkey mechanism -- and yet, Windows was able to steal the focus from my app.</p>
  <p>I really doubt that there is anything like a &quot;backdoor&quot; being used just for this particular purpose (though please correct me if I'm wrong), so, assuming that isn't the case, there must be a way to do this correctly, <em>without</em>  using a hotkey mechanism.</p>
  <p>So the question is, how is this accomplished?</p>
  <h3>Note:</h3>
  <p>Hans noted that the &quot;backdoor&quot; is <code>AttachInputThread</code>, but I'm not really convinced that's what's happening here -- especially since <a href="http://blogs.msdn.com/b/oldnewthing/archive/2008/08/01/8795860.aspx" rel="noreferrer">Raymond says that method can cause hangs</a>. Ideas?</p>