Overflow Error

[MT DOJ Help Desk]

Word 2000

This question may be a little difficult to answer just from the small
snippet of code that I'm posting, but I'll try to explain what is happening.
I have the following code:

While RecordEnd < cbDataLength
AddToLocatesCollection = True
FindMessageMarker
RecordEnd = InStr(RecordStart, cbData, MessageMarker) +
MarkerLength + 1
RecordLength = RecordEnd - RecordStart + 1
cbDataClip = Mid(cbData, RecordStart, RecordLength)
GetRecordNumber
CheckForClearedTag
If AddToLocatesCollection Then CheckRecordExclusionsCollection
If AddToLocatesCollection Then CheckLocatesCollection
If AddToLocatesCollection Then CheckDocument
If AddToLocatesCollection Then LocatesCollection.Add
(cbDataClip)
RecordStart = RecordEnd + 1
Wend

Basically, the contents of cbData come from the clipboard (read in by
another routine), so cbData can contain a HUGE chunk of information. So I
chop up the data and feed it in pieces into cbDataClip. I then pull out a
number of important pieces of information (GetRecordNumber and
CheckForClearedTag), and then run several tests on the data to see if I want
to add it to a collection. The collection that data gets added to is
eventually processed again, and all the items in the collection are pasted
into the document. It all works pretty well.

Tonight, I did my first large scale test of the program, and I encountered
the following error:

Runtime error '6':

Overflow

In debugging the program I found that I had declared RecordStart as and
integer, and the the value of RecordStart was exceeding the limit for an
integer. I was able to fix the bug by declaring RecordStart as Long. This
should work because RecordStart, in practical use, should never exceed the
limit for an integer (my test was purposely the hairiest scenario I could
devise, so was beyond what would be seen in normal use by a factor of
probably about 100), let alone the limit for a Long data type. My test
string of data was almost 45,000 character in length. In practice, the data
being processed at any one time will rarely exceed 1,000 characters, and I
don't know of any instances where it has ever exceeded 5,000 characters.

I thought about redefining cbData each time through, so that it would throw
out the data that has just been processed and, in essence, move everything
remaining in cbData forward. This would prevent RecordStart from ever
exceeding the limit for an integer.

So here's my question. Would it be better to redefine cbData and avoid the
problem of hitting the maximum for an integer, or is my solution good
enough?

-- Tom

MT DOJ Help Desk

Making the world a safer place.

 

[Malcolm Smith]

Tom

The problem here is not your code but your analysis of the problem.

You say that the length of the data 'rarely' exceeds a certain value and
that 'to date' it never got passed a certain size.

If I had a pound for each time I was told that something "would never" do
this or that then I would have retired happy and rich by now. You have
already broken your code with your test data and so you have to ask
yourself whether in the future it would be possible for data to be of a
certain size.

If it is possible, no matter how unlikely, then program for this
possibility.

What I am saying is that there is an art to programming; and one of the
aspects of learning to program well is to develop that odd ability to see
into the future and spot any possible gotchas which may arrive today,
tomorrow or next year.

Other points; you should be using Long Integer types anyway as these are
'native' to the interpreter. Using Integers is actually slightly slower
than Longs and, in any case, most integer functions in VB/VBA use Long
Integers as their base type so time will be spent casting from one type to
another.

Regards
- Malc
www.dragondrop.com

 

[MT DOJ Help Desk]

I asked because at the time I could not see a good way to remove cbDataClip
from cbData, and I was thinking that my existing solution would probably be
good enough. The data comes from a text-based law enforcement system. That
system has a window where messages come in, and that message window is
limited as to the amount of data it can contain, so there's no choice but to
copy over the data in smaller chunks. This is why I think that my previous
solution would probably have been good enough.

Nonetheless, it was rubbing me the wrong way. So tonight I looked at the
issue more closely and was able to find a very simple method of solving the
problem. I only had to modify one line of code, eliminate one line, and add
two other lines, and the problem was fixed with a much more elegant
solution.

Thanks for the info regarding long integers. I did not know that before.

-- Tom

MT DOJ Help Desk

Making the world a safer place.

 

[Malcolm Smith]

Tom,

Excellent and well done! It's even better when one is able to crack the
nut themselves.

Gosh, a law enforcement chappie eh? We need those around here to stop the
grockles interfering with our sheep.

Best wishes
- Malc
www.dragondrop.com