We Keep Coding

Binding WPF textBox Large Text async with possibility of cancellation

I have listbox and for each selected item I need bind data (Large Text) to separate TextBox placed on form.
It works fine with small text less than 16 kb.
but with large text I have UI Freeze because of TexBox Rendering is taking long time.
IDEA is to have Async Binding (even Manually on selected even Line by Line), with ability to have cancelation of binding. Cancellation should occur if new item will selected during a rendering.
P.S. Same code in WinForm works much faster.
Could you help me on that, or give another idea ?
Thank you in Advance.

Read about UI virtualization here: https://learn.microsoft.com/en-us/dotnet/framework/wpf/advanced/optimizing-performance-controls

I found way to achieve result.
1) Using FlowDocumentReader instead of TextBox
2) Load document large text with async, and cancels previous load, if new document load occurs.
Just want to share with a solution to the others. 

Displaying log file in a multiline textbox

I'm writing data to a log file and need to display that data in my WinForms UI. My initial thought was to use a multiline textbox like this:
private void UpdateUITextbox(string text)
{
textBoxStatus.AppendText(text + Environment.NewLine);
}
I don't write a huge amount of text to my log file but over time, it's going to add up and I'll probably end up exceeding whatever the default maxlength for a multiline textbox is. The only thing I can think of to do to prevent this from happening is to hook into the OnKeyPress event handler and check the length of the textbox before I add something to it and, when necessary, to remove the older text to make room for the newer text. But this seems like it would definitely have an impact on performance. Someone please tell me that there is a better way to do this?

A Winforms TextBox has a maximum length of 2GB.
You'll have to worry about usability long before you worry about memory issues - if the log is too long, your users are not going to be able to use it effectively.

We show our log using AvalonEdit. It scales very well up to hundreds of thousands of lines.

Instead of a multi-line text box why don't you use a list box ?
And for the log, its best to add more information to your logs while saving them such as the time.
And on the load read each line which has a date stamp in the range you think is fairly recent.
It is not wise to to load all of your log files just at once. load only the new ones.
If you need to see the older logs,You can still manage that using the time/date stamp solution.

TextBox Text Management

I have a WPF application where I'm trying to create a "diagnostics panel" that's very similar to the "Output Window" in Visual Studio 2010. It simply contains a text box where all types of output are collected and appended in the text box using the .AppendText() method.
We have a couple of customers who leave this diagnostics panel up all the time and never clear it. As a result, a very large amount of text gets displayed as new output continues to come in...
The WPF TextBox has a MaxLength property which I leave set to 0. According to the MSDN documentation, "When this property is set to 0, the maximum length of the text that can be entered in the control is limited only by available memory."
For the customers that leave this panel up, I hate to just let the text and memory grow uncontrolled... I think this may eventually cause the application to hang up...
I am curious if there's a good way to mange this... I want to keep a certain number of lines displayed in the text box and discard the oldest as new lines come in...
Any thoughts?
Thanks!

Why not use a listbox with each sentence getting its own textblock - so you can get virtualization?
http://social.msdn.microsoft.com/Forums/en/wpf/thread/98090161-0abf-4799-bbcb-852dcc0f0608

You could have a DispatcherTimer in your code behind. With this you, you can set it to Tick every 10 minutes (or whatever time period you want). And in the Tick event handler method, you can take the text in your textbox, throw away the all but the amount of text you want to save and then set the that text back to the textbox.
You could also save the text to a log text file. You'd have to figure out what to append to the text file so you won't write the same text to it multiple times. This depends on what exactly your needs are.
DispatcherTimer documenation
Like Xaisoft said, you shouldn't use a TextBox for this, probably a TextBlock instead. You might have to put that inside a ScrollViewer, I don't remember.

Here's how you handle it:
Write the log info to a text file
Write the log info to your text box (although I don't like textboxes, it should be okay.)
When writing to the text box, only display the last maybe 20 or so (play with this) lines. Everything else should "roll off"
If your users really want to save everything, no biggie, it already is saved to that file.
Upon each execution of the app, or at some appropriate interval, roll your logging to a new file.

Storing and displaying rich text efficiently

I need to store significant amounts of rich text in a SQL database, retrieve it and display it.
One font throughout is OK but I need different font sizes/bold/colors.
For now I am using a RichTextBox (WPF) to display it, and XamlWriter.Save/XamlReader.Parse to serialize it to strings to store in the DB. It works well but the RichTextBox is so HUGELY SLOW at displaying the text that it's basically unusable.
Is there a quick way to do this with acceptable performance?
I'm considering doing it with GlyphRun objects, drawing each character as a bitmap and computing all the alignment requirements to fit the destination image etc... But reinventing the wheel on simple colored/sizable text seems really strange in 2011.
EDIT:
Thanks for the answers, didn't see them until now, sorry.
Text is entered by the user from RichTextBoxes as well, basically I just save the resulting string XamlWriter.Save(richTextBox.Document) in the database. Other fields (double/int etc) are also entered by the user from TextBoxes.
As the user queries the database, pages of read-only rich text with colors and formatting is generated from scratch using the fields in the database, including the saved rich text fields above: these are converted from FlowDocuments to Spans and some replacement is done on them (InlineUIContainers which host a class derived from UIElement which references a database entry, inlined in the text, like "see [thisbook]" where [thisbook] references some database entry's ID). MSDN says all that is far too much text for a TextBlock.
That text rendering is the really slow part but there is no way around it, I need that formatting and it's just how the WPF RichTextBoxes are: even when entering a little simple text in the RichTextBoxes, there is a delay between typing and the character appearing on the screen...
For now I still use RichTextBoxes but I keep lots of rendered layouts in memory (the Paragraph/Section/Span objects) and I am careful to rerender only the least amount of formatted text possible when changes/queries are made or different views of the database data are requested by the user.
It's still not fast but it's OK, changing the whole structure (AvalonEdit or FormattedText or GlyphRun) doesn't seem worth it right now, too much work, the whole serialization API with XamlWriter.Save and XamlReader.Parse simplifies much (for FormattedText and GlyphRun, I'd have to come up with a file format myself to save the formatted text to the database).
There is also the possibility of using the OpenXML SDK to create Microsoft Word .docx documents but google says rendering performance isn't great either, and I don't know if embedding an UIElement in the text within an InlineUIContainer and serializing that to be saved in the database would be possible (same problem with AvalonEdit).

Consider throwing away RichTextBox because it is so HUGELY SLOW (spot on). Instead of writing your own text editor check AvalonEdit. Performance wise it beats RichTextBox like a baby.
Or if you need read-only text you could try a TextBlock - it supports simple formatting:
<TextBlock>
<Run FontWeight="Bold">Hello</Run>
<Run Foreground="Green">World</Run>
<Run FontSize="24">!</Run>
</TextBlock>

WPF Multiline TextBox for large content

In a WPF application, I want to build a "Find in Files" output pane, in which I can stream large quantity of text, without re-allocating memory at each line, like the TextBox would do.
The WPF TextBox has a single Text property which stores a contiguous string. Each time, I want to add content, I need to do textBox.Text += "New Text", which is bad.
Ideally, that control would be virtual and require a minimum of resources, just for the visible lines.
I thought about using a standard ListBox with a VirtualizingStackPanel, but it does not allow Text Selection across lines.
(At each new line added, I want the control to update)
Any suggestion?

If you do not expect much more than ten-thousands of search results in your application, a TextBlock control or readonly multiline TextBox will suffice by far.
The TextBox class has an AppendText() method which should be fast enough for you.
If you need text highlighting / formatting then maybe you want to use RichTextBox.

If you have really large content, then unfortunately all the WPF textbox and similar controls are very slow. See this question. You could use AvalonEdit as a replacement.

Have you considered or tried the RichTextBox control?

A StringBuilder, just append the text to the String builder and instead of doing
textBox.Text += moreText;
do
myStringBuilder.Append(moreText);
textBox.Text = myStringBuilder.ToString();
This should take care of the Schlemiel the Painter's algorithm.
Of course, the string builder should have to be a member of your class so it exists through your object's life span.