title: Why is InvokeRequired preferred over WindowsFormsSynchronizationContext?
body: <p>Anytime the beginner asks something like: <a href="https://stackoverflow.com/questions/661561/how-to-update-gui-from-another-thread-in-c">How to update the GUI from another thread in C#?</a>, the answer is pretty straight:</p>
  
  <pre><code>if (foo.InvokeRequired)
  {
      foo.BeginInvoke(...)
  } else {
      ...
  }
  </code></pre>
  
  <p>But is it really good to use it? Right after non-GUI thread executes <code>foo.InvokeRequired</code> the state of <code>foo</code> can change. For example, if we close form right after <code>foo.InvokeRequired</code>, but before <code>foo.BeginInvoke</code>, calling <code>foo.BeginInvoke</code> will lead to <code>InvalidOperationException</code>: <em>Invoke or BeginInvoke cannot be called on a control until the window handle has been created.</em> This wouldn't happen if we close the form before calling <code>InvokeRequired</code>, because it would be <code>false</code> even when called from non-GUI thread.</p>
  
  <p><strike>Another example: Let's say <code>foo</code> is a <code>TextBox</code>. If you close form, and after that non-GUI thread executes <code>foo.InvokeRequired</code> (which is false, because form is closed) and <code>foo.AppendText</code> it will lead to <code>ObjectDisposedException</code>.</strike></p>
  
  <p>In contrast, in my opinion using <code>WindowsFormsSynchronizationContext</code> is much easier - posting callback by using <code>Post</code> will occur only if thread still exists, and synchronous calls using <code>Send</code> throws <code>InvalidAsynchronousStateException</code> if thread not exists anymore.</p>
  
  <p>Isn't using <code>WindowsFormsSynchronizationContext</code> just easier? Am I missing something? Why should I use InvokeRequired-BeginInvoke pattern if it's not really thread safe? What do you think is better?</p>