Introduction
In many projects, I find 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 you 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 sdahlbac 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 using an overly complicated method, as another reader pointed out. Let's have a look at the correct way to do it.
public new void AppendText(string text)
{
if (!string.IsNullOrEmpty(text))
{
if (this.InvokeRequired)
{
TextDelegate callback = base.AppendText;
this.BeginInvoke(callback, new object[] { text });
}
else
{
base.AppendText(text);
}
}
}
And there you have it.
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.
History
- 11-08-2007 - Initial submission
- 11-09-2007 - Eliminated potential performance issues with
AppendText
- 11-16-2007 - Replaced overly complex
AppendText method
