The Coding Hut

In many projects I am finding that I am quickly growing tired of writing delegates to keep various controls thread safe in multi-threaded environments. I have not yet determined whether it is best to create separate utility classes to handle all of the non-thread safe functionality, or to extend the control itself to be thread safe by default. While writing this sample, and seeing how incredibly simple it is to make a control thread safe, I am baffled as to why Microsoft did not build this in from the start.

Extending the TextBox Control

While planning this project I thought, I can simply derive from a TextBox, override the necessary properties and methods with thread safe versions, and be done with it. First, let’s take a look at the Text property, which I was able to use this method for. In the derived TextBox, we override Text as such:

public override string Text
{
  get
  {
    return base.Text;
  }
  set
  {
    if (InvokeRequired)
    {
      TextDelegate callback = SafeSetText;
      BeginInvoke(callback, new object[] { value });
    }
    else
      base.Text = value;
  }
}

And our helper method with delegate

private delegate void TextDelegate(string text);
private void SafeSetText(string text)
{
  base.Text = text;
}

The above code is really all that is required if your only need it so set the Text property of the control. The method I am using here is *almost* the exact same way that it would be done in the main application code, each and every time this ability was needed. When the Text property is assigned to, we check InvokeRequired to see if we are on the UI thread or not. If we are, just set the text and be done with it. If we are not, we then call BeginInvoke and pass the value on to our helper method SafeSetText which then assigns the property on the UI thread.

A step further

Being cocky, here I thought my work was done. WRONG!

Next up, AppendText. Already I ran into a problem with AppendText. If you don’t already know, AppendText is implemented in TextBoxBase. On instinct, my first attempt was to subclass TextBoxBase as well, but as it turns out, this class cannot be derived from. However, all hope is not lost. After poking around a little bit this was quite easily worked around, as such:

public new void AppendText(string AppendingText)
{
  Text += AppendingText;
}

This method effectively hides the internal AppendText method. Being that we already handle the Text property, as you see above, this method is implemented with one line of code.

As a reader pointed out, while it does work, using .Text += brings up some performance issues, especially if the text becomes rather long. After poking around the Framework source and trying a few things I managed to crack this one. First we need to add a couple of imports:

[DllImport]("user32.dll", CharSet = CharSet.Auto)]
public static extern IntPtr SendMessage(HandleRef hWnd, int msg, int wParam, int lParam);
[DllImport]("user32.dll", CharSet = CharSet.Auto)]
public static extern IntPtr SendMessage(HandleRef hWnd, int msg, int wParam, string lParam);

Once we have those, we can get to the meat of the performance friendly method.

public new void AppendText(string AppendingText)
{
if (InvokeRequired)
{
  TextDelegate callback = AppendText;
  BeginInvoke(callback, new object[] { AppendingText });
  return;
}

if (AppendingText.Length > 0)
{
  SelectionStart = TextLength;
  SendMessage(new HandleRef(this, Handle), 0xc5, 0, 0);
  SendMessage(new HandleRef(this, Handle), 0xc2, 0, AppendingText);
  SendMessage(new HandleRef(this, Handle), 0xb9, 0, 0);
  ClearUndo();
  SendMessage(new HandleRef(this, Handle), 0xc5, MaxLength, 0);
}
}

Where did I get this from you ask? If you fire up Reflector (If you don’t no, google it, it’s a must have!) and take a look at TextBoxBase.SetSelectedTextInternal you will find the code that this method is based off of.

The other members implemented are ForeColor, BackColor, and Clear. The implementation is very similar to that above so I am not including it in the article.

Further extending

The method used here can be applied to virtually any control. The only thing to remember is to override members that directly belong to the control you are extending, and to replace those that you cannot override. I am certain I have not covered all members that may need to be thread safe, but these are the most used.

In conclusion

I have not yet had the chance to test how this control performs in the event that it is instantiated from a non UI thread. My assumption at this point is that my efforts here will be moot in that case. Once I am able to test that I will update with my findings. However, for any cases where the control is placed on the form at design time, or at least created on the UI thread, there should be no issues.

An idea I started toying with was to programmatically determine the form that the control is a child of and invoke on that control rather than the TextBox control. Doing so would eliminate the possibility of the TextBox calling BeginInvoke from outside the UI thread if it was created at run time. So far I have not been able to implement this successfully. I will likely add it as soon as I figure it out or someone posts the solution in the comments.