C# performance of a multiline textbox

[Michael Busch]

Hi Guys.

 

I have a problem, hopefully you can help me.

 

I am working with automation software and on my HMI software I have a small performance problem.

Sometimes it is possible to show the code of a control program, what it (sometimes) about 145,000 lines (or more).

 

It comes out of the control as one string.

 

I tried to show the code in a textbox, but this takes about one minute to show up. My HMI is frozen during the time.

Yes, I am using a background worker (async), so I dont understand why it freezes up the whole HMI.

(its only the line filling the multiline textbox).

The code in this case is only one line:

 

>> textbox1.text = codefromControl.code;

 

 

So, I changes to code to a stringbuilder, which is filling the textbox.

I splited the text up in lines, and tried different ways to fill up the textbox (trying as less refreshes of the textbox as possible).

 

The best performance I got was 10,000 lines in 0.7 sec.

But this means its still 15sec to load the screen (its frozen in all scenarios with my background worker, and I dont know why).

 

So, I need to know

 

- how can add my controlcode to the textbox with the best performance?

- some ideas ( I know I dont posted code) why writing to the textbox freezes my HMI and why my background worker isnt working?

- some ideas to increase performace? perhaps different control - listview, richtextbox, etc?

- How can I realize that the screen is loaded, the first e.g. 1000 lines are displayed and the rest is loaded in the background ( I tried this out for a couple os days, but I got it never running (see the other problems, its always freezing up).

 

Thanks a lot th everybody in advance.

 

Mike

 

 

 

 

[Arsalan Tamiz]

I think (as far as I remember) the simple TextBox control is a "simple" control which should be used for simple purpose. Maybe the RichTextBox control is a better solution.

Anyway here are some recommendations,

Do NOT put "large text" in the TextBox in one go, this will hang your UI a little bit. Why? because TextBox control try to render the text in it and this rendering is done in the main UI thread. Thats why your main UI gets freezed. Try using

TextBox1.SuspendLayout();

TextBox1.Text = LargeStringVariable;

TextBox1.ResumeLayout();

This may solve your issue.

But,

I think the best solution is to put text through TextBox.AppendText() method. Here is what you should do,

1) You get a whole large string in a String Variable now you want to put that value in TextBox

2) Create another thread (backgroundworker) and process that large string in chunks.

3) Which means create a loop and read each 100 characters from large text and append them in TextBox using TextBox's AppnedText() method.

Or maybe if you can, try appending the text directly in text box when large string was being created. In this way you don't have to create the large string in first place. You will be adding text directly in text box.

P.S. TextBox1.Text += sometext; is a very bad idea.

[It's time to do something]

Why textBox1.text += sometext is a very bad idea ? Even when
"sometext" here is very short? What is the difference to
textBox1.AppendText(...) ?

[Arsalan Tamiz]

Actually in .net strings are immutable, which means once the string variable is created you cannot change its value. So if we are thinking that += is actually adding some more bytes to the current string is actually a "wrong thinking".

What happens is that a new string variable is created and then its reference is assigned to the variable and previous string variables gets discarded.

So assume that TextBox1.Text already contains a large string. So doing a += will discard the previous value and will create a new value. And it will give worst results if we are doing this repeatedly in a loop. Thats why StringBuilder is a recommended approach in these types of scenarios.

I don't know exactly how AppendText() is working. Maybe internally it is doing the same +=. But I think internally TextBox control is saving the string in a more optimized way (like StringBuilder) rather putting whole string in a single string variable. If thats true (and it should be) then most probably AppendText() method is NOT doing the +=, it will be adding more text like StringBuilder does.

[Davej]

Uh, aren't 99% of these lines going to be off screen anyway? Why not
have the textbox with two scroll buttons? Probably are several ways to
do that, maybe textbox1.txt = code.substring(i,j) or an array of
strings (lines).


On Nov 10, 7:45 am, Michael Busch <michael.n.bu...@googlemail.com>
wrote:

[It's time to do something]

Thank you, I understand that when handling with long strings for many
times, it's the best choice if we use StringBuilder, but when handling
with short strings for several repeats, I think, we can use simple
operations directly on these strings instead.
Thank you again, I'm very glad when someone replies to my questions.
I'm still a newbie in programming C#, so I really need help from
people like you !

[Michael Busch]

Thanks guys for your help.

Its true only 0.01% of lines is shown in the box, so I realized it by showing only the lines which are shown at a moment.

So I also could solve the scrolling problem.......

 

Thanks a lot again.

2010/11/14 Davej <gal...@hotmail.com>

[Benj Nunez]

Below are some links about the textbox control's limitations:

http://www.developmentnow.com/g/36_2004_3_0_0_209735/TextBox-Capacity.htm
http://www.codeproject.com/Answers/121784/csharp-textbox-limit.aspx#answer1


Instead of a multiline textbox, have you tried the RichTextBox control
instead?

According to MSDN, it indicates that:

"Applications that already use TextBox controls can easily be adapted
to make use of RichTextBox controls. However, the RichTextBox control
does not have the same 64K character capacity limit of the TextBox
control. The RichTextBox is typically used to provide text
manipulation and display features similar to word processing
applications such as Microsoft Word."


Source: http://msdn.microsoft.com/en-us/library/system.windows.forms.richtextbox.aspx


Regards,


Benj




On Nov 10, 9:45 pm, Michael Busch <michael.n.bu...@googlemail.com>
wrote: