How To Utilize String Buffering Within A VB Component

Introduction
This article serves as a quick "How To" example for using string buffering to concatenate strings in
a VB component. The example VB code will generate an HTML TABLE record that will be sent to an ASP file
after being populated with data from a database table. The GetRows() method will be used
to acquire the data from an example Access database. (For more information on GetRows()
be sure to read: Displaying Tables with GetRows().)

In many circumstances, sending a Variant array populated by GetRows(), (or a RecordSet) to
an asp file from a VB component is the recommended way to build a HTML TABLE record. Other times you
may choose to build a HTML TABLE record, or other database dependant code, within the VB component
itself before sending it to an ASP file. This may not set well with the "true believers" in not mixing
HTML and VB code. I tend to be agnostic and I find sacrificing orthodoxy for speed is sometimes called
for with server-side components. In any regard, this programming choice is exemplified here.

Rather than sending the HTML code from the VB component with the Response.Write method, you
can optionally collect the HTML within a string and send it back as a complete HTML TABLE record. This
avoids the need to instantiate the asp object within the VB component. It also allows other VB code to
use your component without reference to asp. You're just generating pure HTML code that any COM object
can use. But when putting together a large HTML string in VB, the concatenation operant &
can slow your code down significantly.

We'll be creating two methods, MethodName() and DoBuffer(). The
MethodName() method will acquire data from a database and then use this data to construct
an HTML TABLE record it will send to the calling ASP file in one lump sum. Our ASP file will initially
call the MethodName() method with an SQL statement, a connection string, and the number
of fields used in our sql statement. In order to generate the HTML string with the least use of the
concatenation operant, the MethodName() method will send the string fragments it uses to
build the HTML TABLE record to the DoBuffer() method.

The supporting database file, text, and code, for this article can be downloaded
here. If you're unfamiliar with writing a server-side VB dll, you can read some introductory
articles at my site. This example will include a VB server-side
dll (ActiveX dll) consisting of one class (ClassName) and two methods (MethodName and
DoBuffer). The VB project is named How2Project4.

The connection string value will need to contain the Data Source Name (DSN) that should first be
established with ODBC, although any valid database connection string will work here. ADO will also
need to be referenced in the VB project (see an introductory VB component article on how to do this).

Why Use String Buffering?
If you concatenate strings using the & operant, and you repeat this operation multiple
times, processing time will be significantly delayed compared to using string buffering.
With large amounts of concatenating, I have experienced increases in speed of up to 1000 times greater
when using string buffering. This is primarily due to how VB manages the memory for strings with the
& operant.

THE VB COMPONENT - How2Project4.vbp

The DoBuffer() Method
The DoBuffer() method will be sent a string buffer (strBuffer), the value of
the length of the string data already placed within the buffer (lngBuffer), and the string
to add to the buffer (AddString). These arguments will be declared and sent from our
MethodName() method, which will be covered later in this article.

Notice that the DoBuffer() method is declared as a subroutine rather than a function. This
is because it doesn't really return any data from the method itself. Rather, it manipulates the data sent
by reference from the calling method.
Two local variables need to be declared for internal use.

Dim strHold As String
Dim lngIndex As Long

Now our first line of business will be to determine whether our buffer is large enough to hold the
string data we want to add to it. But before we do this, we want to check out whether our calling
method sent a NULL string or not.

If Not Trim$(AddString) = "" Then

If the calling method sends a NULL string, we'll quietly skip the concatenating process and avoid the
whole affair via this If-Then statement. On the other hand, if the sent string holds
characters, we'll need to check that the buffer is large enough to hold them. To do this the current
length of the data in the buffer is added to the length of the sent string and then the resulting sum
is compared to the length of the overall buffer size.

If lngBuffer + Len(AddString) > Len(strBuffer) Then

If the buffer is large enough to fit the sent string, then the code discussed next will be skipped. This
will occur more often than not since we'll set our string buffer to hold a large amount of data when we
declare it in the MethodName() method. But lets assume that this isn't the first time the
DoBuffer() method was called and that the buffer is too small to add the sent string.
We first need to store the existing buffer data in a local String variable:

strHold = strBuffer

Now we'll go through a Do-Loop to exponentially increase a test of the size of the buffer.
Each time through the loop a new buffer size is tested against the previous buffer size. Once the stored
buffer data and the new string fit the buffer, the loop will be exited.

The 65536 size increase is arbitrary and you can set this number to what you think will be appropriate
for the total size of the string data you're building.
The buffer can now be rebuilt to its new expanded size...

strBuffer = String$(Len(strBuffer) & (65536 * lngIndex), Chr(0))

....and refilled with the stored string data that it previously held:

Mid$(strBuffer, 1, lngBuffer) = strHold

Notice that the string we want to add to the buffer hasn't been added yet. We simply increased the
size of the buffer.
Here's the code that increases the buffer size if our sent string doesn't fit into the buffer. It's
repeated here so you can see it in one glance.

Mission complete! We added a string to a previously established string buffer without using the concatenation
(&) operant except when we needed to expand the size of the buffer, which should be
infrequently since we're doing it exponentially and the original buffer size was set to a size that
was large enough for our string data.