Image of Navigational Map to Home / Contents / Search A Sticky Situation

by Ian Roberts - GUI Computing

Image of Line break

A recent development I was working on seemed to be running along quite nicely; the testers seemed happy, and so was I - until they went live. About a week or two after the app went live, we received the report that a message box stating "OUT OF STRING SPACE" appeared when one of the operators moved the mouse. To then click on the OK button exited the app. Not the result the client wanted. The bug was occurring in a part of the app which was designed to monitor orders being placed on their system. My problem? Well, my problem was that I couldn't get it to fall over...

The only thing we could think of was to run my development environment against their production database. This, for obvious reasons, caused not only a little concern for the client - until we explained that we need only query access, and we would not be writing or changing any of their data. Not surprisingly they then seemed happier with the idea.

Once we had a connection and logon to the production database, we ran the code from within VB and waited to see if it would fall over. About five hours after we started the app it was still working, and we were becoming a little sceptical about the so-called bug. Then it happened - we were presented with an "OUT OF STRING SPACE" error message - and now we were in the dev environment we could define the area where the crash happened.

It seemed to occur while putting a value from the Glue internal array into a VB array. The VB array was then used by TrueGrid in application mode. Another intriguing symptom was as the result set returned by Glue got larger, the error would occur at an earlier index in the VB array.

We put a breakpoint on the routine just after the VB array was REDIMed, and from the debug window successfully wrote data to the last indexes. After running the app to the crash point, we could no longer place data into the locations - yet only moments before we were able to. The thing we found strange was that all the code did after the REDIM was write data into the array. There was nothing in the code that had anything to do with memory allocation.

Maybe TrueGrid was playing up? So I rang Gary Wisniewski in Sydney - who just happened to be the author of the said product. This call proved to be more useful than I had expected, as he mentioned a problem that they had encountered with a very early version of TrueGrid. Apparently it had a problem with not recognizing the VB data segment, where all the arrays, etc., are stored. He had also had a bit of experience with Glue, and believed that while the product worked well at what it was meant to do, this may be the same type of bug. The frustrating thing was that he couldn't give me a work around.

Many litres of midnight oil were burnt, but I could get no closer to a result. It definitely seemed that the problem lay within TrueGrid - or, just as likely, in some obscure interaction between TrueGrid and Glue. Either way, what little hair I have was looking in danger. There is nothing more truly frustrating than a bug in "your" application that just isn't "your" fault. I was not looking forward to informing the client that we'd have to fundamentally change the way this particular screen worked.

And then a minor miracle occurred. Part of the reason for pulling the Glue array into the VB array was due to the initial spec - which wanted to see new lines as quickly as possible (so the system would check for new lines and pull back anything that wasn't previously displayed). But due to the Glue array containing only the new rows, we had to buffer them in a VB array so that all the previously returned rows and the new ones could be displayed.

Never have I been so happy to see a Change Request than the one which appeared requesting we change the system. Meaning, when the grid refreshed it would pull back all the rows, including any previously displayed. This signified if any changes were made to the data in the old rows, it would show up. We could now get rid of the VB array, and code the fetch event directly to hit the Glue array. Problem "solved".

So - no answer as to what tool should get the blame, and no work around; but still a happy client. That's my dose of good luck for this year, I'd say! But the problem was definitely tool-based and, in my estimation, probably an effect of the combination of TrueGrid in application mode and Glue.

The extensibility of VB has been one of its strongest assets, allowing what was a reasonably good development system to be moulded into something more powerful with the help of a few well written tools. This feature has also been one VB's greatest weakness, because no matter how careful you are in developing your code, making sure that you handle errors correctly and testing your code to make sure it performs to satisfaction is very tough indeed. The whole thing can come crashing down around your ears due to an obscure bug in a tool you have used, or in the interaction of a couple of otherwise reliable and stable tools.

Hopefully, as we move to the 32-bit world, and as VBXs, OCXs, and DLLs continue to mature, we will no longer be confronted with clients reporting problems with their systems that are inherently caused by third party add ons.


Written by: Ian Roberts
April 96

Image of arrow to previous article Image of arrow to next article
Image of Line break