title: Why the Overhead for Multi Threaded Access to WPF UI controls?
body: <p>Have I missed something with WPF (and Windows Forms before it) in regards to the need to write a lot of repetitive code when developing multi-threaded applications. Every UI control in the application ends up needing extra lines of code to get and set each property.</p>
  
  <pre><code>internal delegate void SetElementIsEnabledDelegate(UIElement element, bool isEnabled);
  internal delegate void SetBrushesAndTextDelegate(Brush foregroundBrush, string message);
  internal delegate void SetCheckBoxCheckedDelegate(CheckBox checkbox, bool checkedValue);
  internal delegate void SetTextBoxTextDelegate(TextBox richTextBox, string text);
  internal delegate void SetRichTextBoxTextDelegate(RichTextBox textBox, string text);
  
  internal static void SetElementIsEnabled(UIElement element, bool isEnabled)
  {
      if (element.Dispatcher.Thread != Thread.CurrentThread)
      {
          // Execute the same method, but this time on the GUI thread
         element.Dispatcher.Invoke(DispatcherPriority.Normal, new SetElementIsEnabledDelegate(SetElementIsEnabled), element, isEnabled);
         return;
     }
  
     element.IsEnabled = isEnabled;
  }
  </code></pre>
  
  <p>Add another 30 delegates and respecitve methods to that.</p>
  
  <p>As far as I'm aware there is no type safe way around the need to do all the thread invoking. It also seems like this is something that could have easily been taken care of under the hood in the control libraries. Am I doing something wrong and if not why would Microsoft choose not to take care of the thread invoking in the controls?</p>