How many characters can a text box contain and what happens if that amount is exceeded?
Also, can a text box reveal the total number of characters it has and if not how can I calculate this value
Printable View
How many characters can a text box contain and what happens if that amount is exceeded?
Also, can a text box reveal the total number of characters it has and if not how can I calculate this value
I believe it can hold 32K characters.
Don't have access to the documentation right now though.
You can check the current amount of characters using the Len function on the Text property.
I think this should give you your answer.Code:Private Sub Command1_Click()
Text1.Text = String(100000, "A")
Debug.Print Format(Len(Text1.Text), "#,###")
End Sub
OK, it's 65,535 according to MT's test code
I see nothing happens when exceeded other than not accepting more characters.
Here's what I want to do:
The text box will always have it vertical scrollbar at bottom so the last line is always visible so when a certain number of characters have been reached remove the first nnn lines and keep the remaining lines (lines, not characters) in the text box and continue on receiving characters. How to do this?
You think the answer is 65535, but not necessarily.
Modify Mark's code and see what answer you get.
Code:Private Sub Command1_Click()
Text1.Text = ""
Text1.SelText = String(100000, "A")
Debug.Print Format(Len(Text1.Text), "#,###")
End Sub
Here's a more extreme example
This will put a million lines (7,888,896 character length) into a textbox. Assuming you have MultiLine set true, and a vertical scrollbar enabled, you can easily scroll up and down to see all one million lines.
I use the string buffer of 10 million characters because it is much faster and efficient to have a preset string buffer that you use MidStr$ to insert characters into, than try to append the strings (which may take hours or days to complete this same loop of 1,000,000 "concatenations", rather than the few seconds it takes in this example).Code:Private Sub Command1_Click()
Text1.Text = ""
Dim s As String, ts As String
Dim L As Long, p As Long
Dim i As Long
s = Space$(10000000) 'a buffer to build up our output
p = 1 'a pointer into the buffer
For i = 1 To 1000000 'Going to loop a million times
ts = CStr(i) & vbCrLf ' Create a "line" containing the loop index
L = Len(ts) ' Get the length of the line created
Mid$(s, p, L) = ts ' Insert the line into the buffer
p = p + L ' Increment the pointer by the length added
Next
Text1.SelText = Left$(s, p - 1) 'Put the output string into our textbox
Debug.Print Format(Len(Text1.Text), "#,###")
End Sub
The reason for the original 65535 is that the Textbox control is a holdover from the original Visual Basic controls, so much of it is based on the original 16-bit Windows (3.x) operating system (and a string was limited to 64K in the pre-VB4 error).
Thus, the 2^16-1 limit of a 16-bit unsigned number.
But the .Text property is actually a string, and in VB6, a string can theoretically be up to 2GB in length.
So, if you avoid using some of the textbox methods in setting the .Text field, then it can hold munch more data than it will allow you to manipulate.
I've used it to display huge lists of results from a program.
The thing is, if you have more than 64K in the box, you have to avoid using the things that will blow up, like trying to set selStart to anything greater than 64K.
I get 65,535 according to your modification in post 5
However, even if you get more, according to your post 6 I still have to do things based on 65,535 in the normal sense of doing thing like I asked in my post 4 about resetting the text box after so many characters have filled the box
EDIT:
I get 7,888,896 using your code from post 6 but can I use that in the normal way like just putting text in the box like in a chat where many users will be sending chat messages and lines will be added one by one instead of buffering them up like you did
If I can use your approach then that would be great but if I cant then I have to do something like this:
This allows for a limitless amount of messages coming in from many members into one text box without ever having running over the limitCode:'
'
SendMessage txtChat.hwnd, EM_SCROLL, SB_BOTTOM, 0
txtChat = txtChat & MessageFromMember & vbCrLf
If Len(txtChat.Text) > 500 Then
Dim L As Long
SendMessage txtChat.hwnd, EM_SCROLL, SB_BOTTOM, 0
L = InStr(490, txtChat.Text, vbCrLf)
txtChat.Text = Mid(txtChat, L + 2)
End If
SendMessage txtChat.hwnd, EM_SCROLL, SB_BOTTOM, 0
Hmmm, that is interesting.
I might have to try this at home on an older Windows XP 32-bit box.
I'm currently on a Win7 64-bit machine, but I'm pretty sure a year or two ago when the company was still on Win XP 32-bit machines the Len(Text1.Text), would return the real length, not be capped at 64K.
I guess when you run the million line example, do you see a million lines, or does it stop much shorter than that.
Also, to answer your work around question, how many lines would you like to buffer.
Most likely, rather than directly put them in a text box, you would have an array of string that you write into. One line per string makes it much easier to keep track of the lines so you can treat it as a ring buffer and just wrap around so you always have a buffer of say, if your lines average 30 characters, then an array of 20,000 strings to be on the safe side of 64K character limit.
To be honest, if I needed a continual log of text, adding to the bottom, and scrolling off the top, with a fixed amount of lines accessed with a scrollbar, I probably wouldn't use a textbox anyway. Just use a picturebox and a scrollbar control, and print the lines in the picturebox based on the position of the scrollbar.
Got to head home, wife wants some food and is waiting.
Why a Picturebox? I have used picture boxes in the past and they have a vertical limit. Also I need to add my own scroll logic.
I don't care about the vertical limit of a picturebox. You only have to fill the visible portion you can see as you move the scrollbar, or just scroll up a portion when adding new text to the bottom.
By the way, I'm home and I tried the code in post #5 on my old XP-32bit Laptop (I was afraid to try the code in post 6, since this is a old slow machine).
The code only took a couple of seconds on my machine at work, but on this old HP laptop is took 1/2 a minute to put the 100,000 "A"s into the picturebox. But, it did display "100,000". I'm runnig VB6 Pro with SP6.
Attachment 110211
Another interesting thing. I was searching old posts of mine on another forum to look for picturebox, text scrolling code and what did I find.
This very similar code (from 4/20/2012)
and some of the text from that post:Code:Option Explicit
Dim a As String
Private Sub Form_Load()
a = Space$(1000000)
Text1.Text = a
Debug.Print Len(Text1.Text)
End Sub
"This code loads a string with a million spaces.
It assigns the string to a textbox.
It prints out the length of the Text property of the textbox.
The print will say 65535.
You could scroll through all 1 million characters, in the textbox, but if you did something like TextBox1.SelStart = 80000, you would get an exception."
...
So, I obviously was on a machine that did the limit of 65535, not that long ago (less than two years).
I wonder if I had VB6 SP5 on that machine, and maybe they change something in SP6. (at the time I bought my copy of VB6, it installs at SP5, I have to upgrade to SP6 afterward).
In any case, its getting a little late, so I'll post this and continue the search for a scrolling picturebox example.
Ok, found the post (from July 2005) where I gave a quick example of scrolling a lot of text, quickly, on a picturebox.
This was just a minimal example, so doesn't do word wrapping and things like that, but is very little code to provide basic text presentation and scrolling.
The zip file is large because it includes a short novel found on-line to use as a source of some text. Despite its size, it is read quickly and displayed (I just ran it on the old XP laptop I mentioned in the previous post, which is old (about 9 years) and slow.
This machine still can read the file almost instantaneously and scroll immediatedly anywhere in the file as fast as you can move the scrollbar.
A preview of the code (sorry no comments).
Code:Option Explicit
Dim a() As String, L As Long
Private Sub fill_window()
Dim b As Long, i As Long
Picture1.Cls
b = VScroll1.Value
Do While Picture1.CurrentY < Picture1.ScaleHeight
Picture1.Print a(b)
b = b + 1
Loop
Picture1.Refresh
End Sub
Private Sub Form_Load()
Open App.Path & "\test.txt" For Input As #1
a = Split(Input(LOF(1), 1), vbCrLf)
Close #1
L = Picture1.ScaleHeight \ Picture1.TextHeight("Wj")
VScroll1.Max = UBound(a) - L
fill_window
End Sub
Private Sub VScroll1_Change()
fill_window
End Sub
Private Sub VScroll1_Scroll()
fill_window
End Sub
Word wrapping is important as I have no way of knowing the length of any single line coming in. Without that I don't think using the picturebox is going to work
Well, that was only a simple example that showed that you could scroll through text fairly speedily. And, it can offer more flexibility, if you wanted to draw pictures, smiley faces, etc... you would always have the option of adding that if you wanted.
Most examples I've posted in the past I assume are just that an example, not something to be used as is. They would have to be adapted to what the person needs.
For instance, the example is reading a large file. You use probably wouldn't be reading a large file, so that would have to be adapted.
If you were making a chat type program, then you would probably want to split a given line from a chat input into several strings in the array, as you say based on wrapping the text.
There is a TextWrite API call that could be used instead of Picture.Print to write the strings, and it can do word wrapping.
But, there is also the case of do you really want the array to go on endlessly, or just use a Ring Buffer type storage to maintain a specified number of lines, like the cmd window, where you specify 500 lines, or 1000 lines, or some specified amount before the lines are lost.
I did add the TextWrite API to the above example just for a quick test at trying to adding word wrap, yet maintain speed. And since it was wrapping text, went ahead changed the text font to Arial so that the quote characters would display correctly with the test file.
So, don't know if you're interested in the update, as it probably isn't a total solution to the problem, but I guess I'll go ahead an post the updated project (without the text file) in case someone else coming across the thread, might be interested.
An interesting side effect, is since the code treats the wrapped lines as a single entity, when you scroll up or down with the arrow buttons on the scrollbar, it moves up or down one string, which could be multiple lines, so you see a whole phrase scroll into or out of view, not just a single line of text (a part of the phrase) at a time.
Caveat: the file name is hardcoded, so to use this example, need the file from the previous post, or modify the code to use some other text (.txt) file you have available.
No Module1 in project file
You can use a TextBox for this with just a little help. We've been over this here in many threads, and there are probably some CodeBank samples as well.
The VB6 TextBox is a wrapper around a Win32 Edit Control. The wrapper imposes limitations for compatibility with Win16 and Win9x's subset of Win32 capabilities. As far as I can recall right now, Edit Controls in Windows NT (4.0 or later) can handle 2GB or so of text. Windows NT 5.0 (Win2K) and later certainly can.
Most of the information you'd need to subclass a TextBox to extend it (mainly a few simple window messages) can be found right in the MSDN Library that contains VB6's online Help.
Here's one demo program that uses just a couple of the extended operations. It logs 100 messages of a bit over 100K each to a VB6 TextBox. There are also some functions and subroutines defined in there to do most of the other things you asked about.
Nice example:)
BTW: What is the upper limit for a RichTextBox
Unlike Edit controls, RichEdit controls come in several versions.
The VB6 RichTextBox wraps a RichEdit 1.0 Win32 control, but as of Windows 98 this is actually a RichEdit 2.0 control used in RichEdit 1.0 emulation mode.
While a VB6 TextBox wraps an ANSI Edit control, when a RichTextBox uses a RichEdit 2.0 control it creates a Unicode RichEdit 2.0 control. However since RichTextBox is using the ANSI-only RichEdit 1.0 emulation you are still limited to ANSI for its text properties. Yet unlike a TextBox, you can write and read Unicode data in and out of a RichTextBox using subclassing techniques.
There was once a redist version of RichEd20.dll that could be installed into Windows 95 to get RichEdit 2.0 controls.
So the answer is complicated.
Depending on the specific version of Windows and whether RichEd20.dll was back-installed the RichTextBox can be limited to ANSI for some operations but accept Unicode for others. In general if just using the VB6 wrapper's properties and methods it should be considered an ANSI control limited to about 2GB of text.
This can be extended in some cases such as copy/paste operations or by using various window messages, callbacks, and/or the TOM interfaces.
See About Rich Edit Controls for some of the details.
I read from that link "About Rich Edit Controls" that Rich Edit 4.1 and Rich Edit 3.0 comes with Windows XP/SP1 but when I look in my system32 folder I only see riched20.dll and riched32.dll but no riched41.dll and I have XP/SP2
If you go back and read the article more carefully you'll see why. The names of the libraries are spelled out next to the versions of each one.
Rich Edit 3.0 completely replaces 2.0 and has the same DLL file name. Rich Edit 4.1 uses an entirely different file naming pattern.
Sorry, I don't do VB6 as much as I used to and didn't catch (or remember) that sometimes when you add a new file to a project, VB6 defaults to putting the file in the IDE directory, rather than the directory where your project is.Quote:
Originally Posted by jmsrickland
Since I'm on a different machine and don't have access to the file, I've recreated it. It was just the API declarations needed for the DrawText function.
I've updated the Zip file back in post 14 to now include that recreated Module1, although subclassing a textbox is probably the preferred solution, and the hacky DrawText usage is probably OBE (overcome by events).