64k limit in string functions (Wd2000)

Topic

New Reply

Some of the string functions in Word2000 VBA seem still limited to less than 64 kByte string length.

Selection.TypeText will cut off a string longer than 64kB:

Selection.TypeText String(66000, "?")

I also ran into problems trying to write a string to a file (opened in Binary mode) with Put if the string is longer than 64kB.

Are limitations like these documented somewhere (Knowledge Base)? Are they still present in Word2002?

TIA, Klaus

Reply | Quote

Replies

In VBA, fixed-length strings are limited to about 64000 bytes. Not so for non-fixed length strings.

The implication is that the String function is using a fixed-lengh string for intermediate or final output.

Reply | Quote

Hi Howard, thank you for your reply.

In my example it is .TypeText, not String(), that only works with strings shorter than 64kByte.
I don’t think an implicit conversion from a non-fixed string to a fixed-length string is involved, since in my example, the output is a lot shorter than 64kB:

Selection.TypeText String(65537, "a")

outputs a single, lonely “a”.

It seems to be an undocumented limitation in .TypeText, probably to speed this function up (it is a lot faster than .InsertAfter).

I still hope the above line outputs 65537 a’s in Word2002; it would be one more reason to upgrade. Could someone with Word2002 please check that?

Thank you very much in advance, Klaus

Reply | Quote

The implication from the following is that the String fuction is working correctly, however, for various lengths, there is an error, implying that fixed-length strings might be used internally for Selection.TypeText.
However, there is no problem if the Range object is used instead of the Selection object.

Option Explicit

Private Sub TestStringFunction()
Dim strTemp As String
On Error Resume Next
‘ Debug.Print String(100, “a”)
‘ Selection.TypeText String(100, “a”)
‘ Debug.Print String(65535, “a”)
‘ Selection.TypeText String(65535, “a”)
‘ strTemp = String(65535, “a”)

‘ Debug.Print String(65536, “a”)
‘ Debug.Print String(65537, “a”)
‘ Debug.Print String(65538, “a”)
‘ Debug.Print String(100000, “a”)
‘ Selection.TypeText String(100000, “a”)
‘ strTemp = String(100000, “a”)
Selection.Range.InsertAfter String(100000, “a”)
If Err.Number 0 Then
Debug.Print Err.Number & vbCr & Err.Description
Else
Debug.Print Len(strTemp)
End If
End Sub

Reply | Quote

Nice research ; but I never got any errors.

The problem definitely is with .TypeText;
Selection.Range.InsertAfter String(100000, “a”) works,
Selection.InsertAfter String(100000, “a”) works,
Selection.TypeText String(100000, “a”) doesn’t.

None of the three throws an error.

Klaus

Reply | Quote

I just *did* get an error message “4609: String too long” when trying to split up the string into chunks:

  While Len(myString) > 65500
    Selection.TypeText Left$(myString, 65500)
    myString = Mid$(myString, 65501)
  Wend
  Selection.TypeText myString

With chunks of size 65000 bytes, it works fine, and with chunks of 66000 bytes, it doesn’t work (but I also don’t get an error message any more)

Seems definitely a bug in Word-VBA that the error 4609 doesn’t appear for strings longer 64kByte, but only for strings a bit shorter than 64kByte.

Klaus

Reply | Quote

Klaus,

Just out of curiosity, what is the practical application of inserting long strings like this into a Word document?

Thanks,
Gary

Reply | Quote

Hi Gary,

I’m converting Word-Docs from/to tagged file formats.
I’m reading XML-files or other tagged files (whole books of several MBytes) into a string variable and parse/edit it with VBA string functions (Split, Join, Replace…). This is a lot faster than opening the text file and using the Word Object Model to make the necessary changes.
When I’ve gone down that road as far as possible, I write the string into a document, and do the rest of the conversion with the Object Model (mostly assigning paragraph and character styles to different ranges).
It’s a bit frustrating that parsing/editing the string is pretty fast, but it takes up to several minutes to get the string into a Word document. Since .TypeText is a lot faster than .InsertAfter for short strings, I had hoped to speed up the process with .TypeText, and it did seem to work … until I noticed I had lost most of my text, that is

Klaus

Reply | Quote

Hi Klaus,

Rather than .TypeText or .InsertAfter, could you use something like:

NewDoc.Content = strToInsert

Also, Selection/Range.InsertFile is very fast, but this would require you to save the string variable back to some kind of file first I guess…

Gary

Reply | Quote

Thank you Gary, I’ll try your second suggestion. I checked the first already, and it didn’t seem to be (much) faster. For most files I work with (<3 MByte), the speed is acceptable already (64kB to Microsoft; seems to be a genuine bug that it messes up the string without giving an error message.

Klaus

Reply | Quote

If you want speed, the Range object is at least umpteen times faster than the Selection object.

Reply | Quote

In general, I’d agree, but there are exceptions — like this.
With my files, Selection.TypeText is about 10% faster than Selection.InsertAfter which in turn is about 10% faster than Range.InsertAfter.

The difference probably results from the fact that .InsertAfter selects the inserted text, while .TypeText doesn’t (and so makes less work for the graphics output), and from the fact that the position of the insertion (that is, the end of the file) has to be calculated by Word when using a Range, whereas with the Selection, it is known already.

Speed differences as small as that don’t mean a thing anyway … so let’s not quarrel

Klaus

Reply | Quote

Just curious whether it helps to keep the document invisible as long as possible, if speed issues are attributable to screen activity? You have a great application for benchmarking. (Okay, I’m too lazy to test it myself.)

Reply | Quote

I saw that too.
Just use the Range object instead of the Selection object.

Reply | Quote

If it’s a VBA issue, then 2002 will be the same because it uses VBA6, same as Word 2000.

Reply | Quote

Hi Charlotte,

I fear so, too

My goal was to put very long strings (>1 MByte) into a Word document as quickly as possible.
Selection.TypeText doesn’t seem to be faster than Selection.InsertAfter if I have to split the strings up into 64kByte chunks first.

The only other alternative I could think of was to write the string into a text file, and then append the text file. But — as is to be expected — this is slower still.

Klaus

Reply | Quote

Not necessarily.
Bugs do get fixed.

Reply | Quote

However, limitations that are clearly spelled out in the documentation don’t usually get counted as bugs.

Reply | Quote

Confirmed. Your

Selection.typetext line

produces a single “a” in Word 2002.

Reply | Quote

Hi Kevin,

You look genuinely shocked … well, thank you for the news, even if it’s bad.

Klaus

Reply | Quote

I’m always shocked whether it works or not.

Reply | Quote

Just to nail it down… in Word 2002,

   Selection.TypeText String(65280, "a")

and anything smaller succeeds, but

   Selection.TypeText String(65281, "a")

and anything larger fails.

Reply | Quote

Ok. Now I want to know why.

Obviously, there’s a 64k limit on the number of bytes .typetext can handle. I thought such limitations were only relevant in a 16-bit world. Isn’t Word a 32-bit program? Are we mired in a segment:offset world still?

But 64K is 65536 and that minus 65280 is 256. What are those 256 bytes for?

I’ll not have a moment’s peace till I know what MS is up to.

Reply | Quote

In order to understand such things, one has to understand something about algorithms and they are (ab)used in implementations of applications, compilers, interpreters, etc.

In effect, Team A lays out the functional specs for a product; Team B lays out the design specification; and Team C does the actual coding.

Often Team B and/or Team C is “more junior” or “less experienced” or ” have those suffering from the NIH (not invented here) disease), etc.

It is quite common for the lesser experienced programmer to “fall in love” with some coding structure that saves a few bytes, not understanding the consequenses of their (usually, well-intended) decision.

Of course a proper SQA review should catch such foolishness, but companies just do not do adequate reviews, in many cases, because they do not allow time for such review.

In the case of fixed-length strings, the programmer was being “clever” in limiting the counter to 16 bits, but, in addition to the length, there’s other things to keep track of for a string, e.g., the character code used.

Note that while most of you may believe that the sector size on a CD based media is 2048 bytes, it is really something like 2352 bytes to accommodate error correction, identification of the mode of recording, etc.

Understanding such details is a time consuming process. End users should ignore such distractions.

Reply | Quote

Thanks to all who answered!

re Jscher2000: Yes, this definitely is a case in which “Application.ScreenUpdating = False” helps a lot. The code I finally used is “ActiveDocument.Content.InsertAfter myString”.

re Jay Freedman: Thank you for the confirmation; really seems to be exactly the same in Wd2000/2002.

Contrary to what I assumed in my very first post, .Put doesn’t have the same problem as .TypeText; I remembered getting maimed text files in the past, but must have made some other dumb mistake.

I had feared a bit that the limitation of .TypeText was well known, or documented somewhere (the Knowledge Base often has the answers, but I have notorious trouble locating the information).

A problem seems to be that the online help doesn’t properly discern between fixed-length and variable-length strings: Both .InsertAfter and .TypeText are listed as taking a string as argument; as this thread showed (thanks, Howard!), .TypeText seems limited to fixed-length strings.

I reported this missing documentation and fact that you get an error alert for string lengths between 64kB-256 and 64kB, but not for strings > 64kB, to Microsoft.

Well, I guess VB.Net in the next version of Word will do away with restrictions like this

Klaus

Reply | Quote