About the Code

The code in this book has been carefully tested by at least three individuals—myself, my editor Ron Petrusha, and the technical reviewer, Matt Childs. Indeed, I have tested the code on more than one machine (with different operating systems) and at more than one time (at least during the writing of the book and during the final preparation for book production).

Unfortunately, all three of us have run into some deviations from expected behavior (that is, the code doesn't seem to work as advertised, or work at all) as well as some inconsistencies in code

Tea xiHy®

behavior (that is, it works differently on different systems or at different times). Indeed, there have been occasions when one of us did not get the same results as the others with the same code and the same data. Moreover, I have personally had trouble on occasion duplicating my own results after a significant span of time!

I suppose that this shouldn't be entirely surprising considering the complexity of a program like Excel and the fallibility of us all, but the number of such peccadilloes has prompted me to add this caveat.

Offhand, I can think of two reasons for this behavior—whether it be real or just apparent—neither of which is by any means an excuse:

• The state of documentation being what it is, there may be additional unmentioned requirements or restrictions for some code to work properly, or even at all. As an example, nowhere in the vast documentation—at least that I could find—does it say that we cannot use the HasAxis method to put an axis on a chart before we have set the location of the data for that axis! (This seems to me to be putting the cart before the horse, but that is not the issue.) If we try to do so, the resulting error message simply says "Method 'HasAxis' of object '_Chart' has failed." This is not much help in pinpointing the problem. Of course, without being privy to this kind of information from the source, we must resort to experimentation and guesswork. If this does not reveal the situation, it will appear that the code simply does not work.

• Computers are not static. Whenever we install a new application, whether it be related to Excel or not, there is a chance that a DLL or other system file will be replaced by a newer file. Sadly, newer files are not always better. This could be the cause, but certainly not the excuse, for inconsistent behavior over time.

The reason that I am bringing this up is to let you know that you may run into some inconsistencies or deviations from expected behavior as well. I have tried to point out some of these problems when they occur, but you may encounter others. Of course, one of our biggest challenges (yours and mine) is to determine whether it is we who are making the mistake and not the program. I will hasten to add that when I encounter a problem with code behavior, I am usually (but not always) the one who is at fault. In fact, sometimes I must remind myself of my students, who constantly say to me, "There is an error in the answers in the back of the textbook." I have learned over 20 years of teaching that 99% of the time (but not 100% of the time), the error is not in the book! Would that the software industry had this good a record!

I hope you enjoy this book. Please feel free to check out my web site at http://www.romanpress.com.

0 0

Post a comment