Not built into .NET, that I am aware of.  TextBoxBase only deals in  
discrete changes to the text.

Personally, I'd approach it by implementing my own TextWriter rather than  
using the StringWriter.  In your TextWriter, then you would just add new  
text to the text box as it comes in.

In addition to avoiding the business of having to repeatedly create a  
StringWriter, do some work, check the StringWriter, close it and create a  
new one, it would also clean up the code by allowing all of the trace  
listener stuff to be somewhere else rather than stuck in the middle of  
your processing loop.

It would even make it easy to modify the code so that trace output was  
buffered and/or properly marshaled over to the GUI thread.  This latter is  
important, because the code you posted appears to be doing time-consuming  
work on the main GUI thread, which is not a good idea.  That loop should  
be executing on a different thread, with the Control.Invoke() or  
Control.BeginInvoke() method used for updating the text box as necessary.

Finally note that you have a general performance problem with logging  
trace information this way anyway.  For relatively small amounts of text  
(hundreds of lines) this is probably okay.  But for every line of text you  
add, you have to instantiate a whole new string and then copy it back to  
the text box (I believe that internally the text box class does not use  
the String class, so assigning to the Text property involves another copy  
of the text, and possibly retrieving that property does as well).

In other words, as your text in the text box gets longer and longer, you  
incur more and more overhead just to update it.  This will eventually  
bring the logging to a crawl.  You can delay the inevitable by using a  
StringBuilder or String[] to accumulate the text, assigning the current  
value to the Text or Lines property, respectively.  But the proportional  
overhead will still exist.

The reason I bring that up is that if you are concerned about the kludgy  
aspect of your current implementation, creating and closing and recreating  
StringWriters and StringReaders over and over, perhaps this code is  
important enough to warrant implementing some more robust visual logging  
than just using the TextBox class.  :)  And actually, as long as you don't  
have a need to interact with the text (select, copy, paste, etc.) it  
wouldn't actually be that hard to write a custom control that displays an  
arbitrary amount of text efficiently.  Heck, you could even make that  
custom control host a TraceListener that could be used to directly connect  
it to the trace output.  :)

Pete