making a text box more efficient
-
It would still have to render that string, so it would still have to read it. It might have to perform less processing if the string was significantly longer than the viewable area, but that seems like a fringe case. Also, ListBox doesn't have the same features as a TextBox (e.g., the ability to copy all the text at once). I wouldn't base my decision on using TextBox/ListBox on performance... rather, I'd base it on the features of each.
I agree functionality is the determining factor, assuming performance is adequate. The OP stated "logging" and "the textbox slowing down as text gets added" which tells me significantly more text is present than can be seen at any one point in time. BTW: copying all text (or a contiguous block of selected lines) from a ListBox isn't hard at all; it is what I often add to a ListBox-based logging Control. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
I agree functionality is the determining factor, assuming performance is adequate. The OP stated "logging" and "the textbox slowing down as text gets added" which tells me significantly more text is present than can be seen at any one point in time. BTW: copying all text (or a contiguous block of selected lines) from a ListBox isn't hard at all; it is what I often add to a ListBox-based logging Control. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
Luc Pattyn wrote:
significantly more text is present than can be seen at any one point in time
I meant horizontally (i.e., each item), not vertically (all items). I was basing my performance assertion on the assumption that a render would have to be performed when each item is added, which actually may not be true now that I think about it.
Luc Pattyn wrote:
copying all text (or a contiguous block of selected lines) from a ListBox isn't hard at all
Yeah, but it may not be obvious to the user. And what about modifying text? Different controls for different functionality. Anyway, my main point was that TextBox should probably suffice. The user was having problems with appending text taking more time as there was more text added, and that has nothing to do with the size of each item added to the textbox (unless the OP was adding larger and larger items). Just didn't like to see people jumping in saying to avoid TextBox like the plague. TextBox has feelings too!
-
Luc Pattyn wrote:
significantly more text is present than can be seen at any one point in time
I meant horizontally (i.e., each item), not vertically (all items). I was basing my performance assertion on the assumption that a render would have to be performed when each item is added, which actually may not be true now that I think about it.
Luc Pattyn wrote:
copying all text (or a contiguous block of selected lines) from a ListBox isn't hard at all
Yeah, but it may not be obvious to the user. And what about modifying text? Different controls for different functionality. Anyway, my main point was that TextBox should probably suffice. The user was having problems with appending text taking more time as there was more text added, and that has nothing to do with the size of each item added to the textbox (unless the OP was adding larger and larger items). Just didn't like to see people jumping in saying to avoid TextBox like the plague. TextBox has feelings too!
aspdotnetdev wrote:
Just didn't like to see people jumping in saying to avoid TextBox like the plague. TextBox has feelings too!
No problem. The only Controls I'm willing to disrespect are PictureBox and NumericUpDown; the former because it is only good at extremely simple things, for which I don't need a specialized Control; the latter because its arrow clicking is just awkward IMO. TextBoxes are great, especially for displaying text that doesn't change all the time; I do prefer them in single-line mode though. And when in doubt, I'll use a ListBox, but that you knew already. :-D
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
Dave Kreskowiak wrote:
The actual value is managed by Win32, not .NET, by sending window messages like EM_SETTEXT, EM_REPLACESEL, and the like.
My guess is that Win32 uses a structure similar to a StringBuilder to ensure append operations are O(1) rather than O(n). For example, they might use mutable strings that double in size each time the capacity is exceeded.
Dave Kreskowiak wrote:
I didn't say there was any.
You said there was nothing funky going on, but you didn't show the whole picture. There are calls to other functions that probably manage things more intelligently than you seem to think append operations are handled.
aspdotnetdev wrote:
My guess is that Win32 uses a structure similar to a StringBuilder
Kind of. In Win32, all a string really is is a coniguous block of memory storing the bytes of the characters. When the Text property is set, all it's doing is sending a pointer to the new string to the Win32 window. If you use AppendText, it uses Win32 messages to tell the window what text to select and what to replace it with. Win32 will allocate a new block of memory and do the appropriate copy operations to insert the new text into the string in the new memory location, then free the original string.
aspdotnetdev wrote:
You said there was nothing funky going on,
There isn't. Not to me anyway. It's just backed by an unmanaged field in the window properties. The Text property you get in return is exactly the same as if you sent a WM_GETTEXT message to the TextBox window handle and processed the pointer it sends back. StringBuilder just keeps an array of characters and exposes methods to manipulate that array. Arrays in .NET are immutable. If it needs to expand that array, it has to create a new one of the needed size, copy the data over, then free the original array. Under Win32 (or C), that memory block can be expanded in place if there is space available for it. If not, realloc (of other variant) will automatically allocate a new block copy the data over and free the original block of memory. In either case, a pointer is returned to the expanded block of memory, whether it moved or not. StringBuilder doesn't have the option of not moving the data.
aspdotnetdev wrote:
There are calls to other functions that probably manage things more intelligently than you seem to think append operations are handled.
No, I know how they're handled, I read the code and did the research on what the SendMessage calls were doing. A background in Win32 also helps tremendously.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009... -
aspdotnetdev wrote:
A new string need not be created each time text is appended to a textbox. As Luc said, you can use AppendText to add to a textbox
...which creates a new string... AppendText merely takes into account the current values of the Selection properties of the TextBox and replaces that text or appends text to that selection. In any case, the selected string is replaced or text is appended to the String, resulting in a new string being created and parsed when the control needs to render itself. The longer that string gets, the more time it takes to parse it and render what's visible.
aspdotnetdev wrote:
Textbox probably stores the text as an array of strings
No, it doesn't. It uses a String field all the way back up it's inheritance chain.
aspdotnetdev wrote:
and likely has special getters and setters for the Text property (e.g., if a line was added via AppendText, then add that to the string returned from Text when the getter is called).
Nope. If you open Reflector and lok for yourself, it's quite easy to see. Here's the code for the Text property of the TextBox class:
Public Overrides Property [Text] As String
Get
Return MyBase.Text
End Get
Set(ByVal value As String)
MyBase.Text = value
Me.selectionSet = False
End Set
End Property...and for AppendText (comes from TextBoxBase):
Public Sub AppendText(ByVal [text] As String)
If ([text].Length > 0) Then
Dim num As Integer
Dim num2 As Integer
Me.GetSelectionStartAndLength(num, num2)
Try
Dim endPosition As Integer = Me.GetEndPosition
Me.SelectInternal(endPosition, endPosition, endPosition)
Me.SelectedText = [text]
Finally
If ((MyBase.Width = 0) OrElse (MyBase.Height = 0)) Then
Me.Select(num, num2)
End If
End Try
End If
End SubThere's nothing special in there. As for WordWrap, that may or may not be a viable option depending on requirements. TextBox works with monolithic strings no matter what you do. ListBox works with an array of Objects and can handle much more of and more varied content than a TextBox can.
-
aspdotnetdev wrote:
My guess is that Win32 uses a structure similar to a StringBuilder
Kind of. In Win32, all a string really is is a coniguous block of memory storing the bytes of the characters. When the Text property is set, all it's doing is sending a pointer to the new string to the Win32 window. If you use AppendText, it uses Win32 messages to tell the window what text to select and what to replace it with. Win32 will allocate a new block of memory and do the appropriate copy operations to insert the new text into the string in the new memory location, then free the original string.
aspdotnetdev wrote:
You said there was nothing funky going on,
There isn't. Not to me anyway. It's just backed by an unmanaged field in the window properties. The Text property you get in return is exactly the same as if you sent a WM_GETTEXT message to the TextBox window handle and processed the pointer it sends back. StringBuilder just keeps an array of characters and exposes methods to manipulate that array. Arrays in .NET are immutable. If it needs to expand that array, it has to create a new one of the needed size, copy the data over, then free the original array. Under Win32 (or C), that memory block can be expanded in place if there is space available for it. If not, realloc (of other variant) will automatically allocate a new block copy the data over and free the original block of memory. In either case, a pointer is returned to the expanded block of memory, whether it moved or not. StringBuilder doesn't have the option of not moving the data.
aspdotnetdev wrote:
There are calls to other functions that probably manage things more intelligently than you seem to think append operations are handled.
No, I know how they're handled, I read the code and did the research on what the SendMessage calls were doing. A background in Win32 also helps tremendously.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...And after all that research, do you still think setting WordWrap to false and using AppendText will not solve the OP's problem of ever increasing processing time when appending text repeatedly to a textbox?
-
Dig a little deeper with Reflector and you'll see that neither TextBox nor TextBoxBase maintain any .Net string at all - they are simply wrappers around the Win32 text box. Anyone know, or care to guess, how Win32 handles a window's text value?
That's what I've been saying!! All the Text property in a Win32 window is is a block of memory containing the string. The Text property uses SendMessage, passing a pointer to the .NET string, to communicate with the window and the window maintains the string using WM_SETTEXT, WM_GETTEXT, EM_REPLACESEL, ... The base window uses standard C memory functions to allocate and resize any blocks of memory it needs.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009... -
And after all that research, do you still think setting WordWrap to false and using AppendText will not solve the OP's problem of ever increasing processing time when appending text repeatedly to a textbox?
Not entirely. Sure it will buy time and extended the performance boundry, but I think (haven't tested yet!) that boundry just get pushed back. I don't think it was eliminated. ListBox only renders the items that are visible. I believe the TextBox has to render the entire string no matter what's visibile. That's a little more research that I won't have time for until late today.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009... -
That's what I've been saying!! All the Text property in a Win32 window is is a block of memory containing the string. The Text property uses SendMessage, passing a pointer to the .NET string, to communicate with the window and the window maintains the string using WM_SETTEXT, WM_GETTEXT, EM_REPLACESEL, ... The base window uses standard C memory functions to allocate and resize any blocks of memory it needs.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009... -
Not entirely. Sure it will buy time and extended the performance boundry, but I think (haven't tested yet!) that boundry just get pushed back. I don't think it was eliminated. ListBox only renders the items that are visible. I believe the TextBox has to render the entire string no matter what's visibile. That's a little more research that I won't have time for until late today.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...Dave Kreskowiak wrote:
I believe the TextBox has to render the entire string no matter what's visibile.
Not if you turn off word wrap. With a constant height per line, the visible lines can be calculated using the scroll offset. I speak from experience that performance without word wrap is much better when huge amounts of text is involved.