Click here to Skip to main content
15,126,221 members
Articles / Desktop Programming / Windows Forms
Posted 8 Nov 2007


30 bookmarked

A Self Contained Thread Safe TextBox Control

Rate me:
Please Sign up or sign in to vote.
4.77/5 (12 votes)
16 Nov 2007CPOL4 min read
This control will eliminate the need to ensure that updates are thread-safe from your main program. Everything is handled automatically the way it should have been in the first place.
Screenshot - ThreadSafeTextBoxDemoScreenShot.jpg


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
    return base.Text;
    if (InvokeRequired)
      TextDelegate callback = SafeSetText;
      BeginInvoke(callback, new object[] { value });
      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 });

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.


  • 11-08-2007 - Initial submission
  • 11-09-2007 - Eliminated potential performance issues with AppendText
  • 11-16-2007 - Replaced overly complex AppendText method


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Jim Weiler
Software Developer
United States United States
No Biography provided

Comments and Discussions

QuestionThread Safe Application Pin
ramarch26-Nov-07 19:27
Memberramarch26-Nov-07 19:27 
GeneralNormalisation of behaviour [modified] Pin
Alex Cater25-Nov-07 9:12
MemberAlex Cater25-Nov-07 9:12 
GeneralRe: usage scenarios ? Pin
jmacdona13-Nov-07 4:23
Memberjmacdona13-Nov-07 4:23 
Questionusage scenarios ? Pin
BillWoodruff12-Nov-07 21:30
mveBillWoodruff12-Nov-07 21:30 
AnswerRe: usage scenarios ? Pin
Jim Weiler12-Nov-07 22:14
MemberJim Weiler12-Nov-07 22:14 
GeneralAppendText performance implications Pin
sdahlbac8-Nov-07 23:13
Membersdahlbac8-Nov-07 23:13 
Your implementation of AppendText using .Text += ...
has huge performance implications, after all AppendText is there for a reason.

This becomes most apparent if the textbox already contains much text and you repeatedly append text.

For certain applications this may not be an issue, but it is certainly something you have to be aware of.
GeneralRe: AppendText performance implications Pin
Jim Weiler9-Nov-07 4:25
MemberJim Weiler9-Nov-07 4:25 
AnswerRe: AppendText performance implications [modified] Pin
Jim Weiler9-Nov-07 7:59
MemberJim Weiler9-Nov-07 7:59 
GeneralRe: AppendText performance implications Pin
Richard Deeming13-Nov-07 9:21
mveRichard Deeming13-Nov-07 9:21 
GeneralRe: AppendText performance implications Pin
Jim Weiler13-Nov-07 11:26
MemberJim Weiler13-Nov-07 11:26 
GeneralIf you found this helpful please vote! Pin
Jim Weiler8-Nov-07 12:47
MemberJim Weiler8-Nov-07 12:47 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.