Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6!:Debugging And Distributing Your Applications
function GetCookie (name) { var arg = name + "="; var alen = arg.length; var clen = document.cookie.length; var i = 0; while (i < clen) { var j = i + alen; if (document.cookie.substring(i, j) == arg) { var end = document.cookie.indexOf (";", j); if (end == -1) end = document.cookie.length; return unescape(document.cookie.substring(j, end)); } i = document.cookie.indexOf(" ", i) + 1; if (i == 0) break; } return null; } var m1=''; var gifstr=GetCookie("UsrType"); if((gifstr!=0 ) && (gifstr!=null)) { m2=gifstr; } document.write(m1+m2+m3);            Keyword Title Author ISBN Publisher Imprint Brief Full  Advanced      Search  Search Tips Please Select ----------- Components Content Mgt Certification Databases Enterprise Mgt Fun/Games Groupware Hardware IBM Redbooks Intranet Dev Middleware Multimedia Networks OS Prod Apps Programming Security UI Web Services Webmaster Y2K ----------- New Titles ----------- Free Archive To access the contents, click the chapter and section titles. Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6! (Publisher: The Coriolis Group) Author(s): Peter G. Aitken ISBN: 1576102815 Publication Date: 08/01/98 function isIE4() { return( navigator.appName.indexOf("Microsoft") != -1 && (navigator.appVersion.charAt(0)=='4') ); } function bookMarkit() { var url="http://www.itknowledge.com/PSUser/EWBookMarks.html?url="+window.location+"&isbn=0"; parent.location.href=url; //var win = window.open(url,"myitk"); //if(!isIE4()) // win.focus(); } Search this book:  














Previous
Table of Contents
Next




Chapter 26Debugging And Distributing Your Applications


Writing a Visual Basic program is not enough. You must also debug it so it works properly, and you must distribute it to your end users.
To my mind, writing a Visual Basic program is the fun part. Okay, it may not always be fun, but there’s always the challenge of making the computer do just what you want it to do. Software development means more than just writing a program, however. Once the program is nearing its final form, you need to be sure it is free of bugs. Then, of course, you must tackle the job of actually distributing the program to the end users. Debugging and distributing may not be as much fun as writing the program, but they are necessary tasks.
Finding And Fixing Program Bugs
The time has come for us to take on program bugs—what they are and what you can do about them. Bugs are one of the two main types of problems your programs can experience. (The other—runtime errors—was covered in Chapter 25.)

What’s A Bug?
A bug is a code error that prevents your program from operating correctly. We’re not talking about an error that prevents the program from executing or that can be caught by Visual Basic’s error-trapping mechanisms. Rather, a bug is a logical mistake in the program’s source code that causes the program to behave incorrectly. Here are some examples of the kinds of problems bugs can cause:

•  A financial program that calculates and displays incorrect loan payments
•  A graphics program that applies improper colors to images
•  Any program that does not respond properly to user commands

These are just a few examples; there are plenty more, and I can guarantee that you will run into some of them. Dealing with bugs is a two-part process that begins with avoiding them in the first place. No, it isn’t feasible to avoid all bugs in all programs (at least I haven’t been able to), but you can greatly decrease their frequency with good programming practice. (As you have probably noticed by now, teaching and encouraging good programming practices are among the major goals of this book.)

Here are some of the most essential guidelines to follow when it comes to avoiding program bugs:

•  Always use Option Explicit, so variable declaration is required. This prevents the pernicious “misspelled variable name” error that is perhaps the most common cause of bugs in Visual Basic.
•  Divide your code into relatively small, manageable procedures. Large, complex procedures are more prone to bugs, and more difficult to debug, than short, simple ones.
•  Use global and public variables sparingly. Stick with local variables within pro-cedures as much as possible, resorting to global and public variables only when unavoidable.
•  Use the proper data type for your program’s data. Using type Integer for certain calculations can result in rounding errors, which can cause bugs.

Regardless of how carefully you work, some bugs are likely to crop up in your programs—particularly as you move into more complex projects. Almost all bugs can be traced to a program variable taking on an improper value or to program execution taking an unexpected path (or a combination of both). Visual Basic provides debugging tools that help track down both kinds of problems.

Using The Debug.Print Statement
With the Debug.Print method, you can display information about program status during execution. The information is displayed in the Immediate window, which opens automatically when you execute a program within the Visual Basic environment. To use Debug.Print, include the statement in your code, followed by a list of one or more program variables or string constants that you want to display. For example, the statement


Debug.Print X, Y


will display the values of the variables X and Y in the Immediate window. Likewise, executing the statement



Debug.Print “Entering Calculate procedure”


will display the indicated text. Each Debug.Print statement outputs on a new line in the Immediate window. If you execute Debug.Print with no arguments, it outputs a blank line. You can display the value of any program variables or object properties with Debug.Print. You can also use it to evaluate and display the result of any Basic expression.
The beauty of the Debug.Print statement is that it is ignored when you create an executable version of your project. It is operative only when a program is executed within the Visual Basic development environment, and it has no effect on the size or execution of the final program. Thus, you can use it freely during program development.
Setting Breakpoints
A breakpoint causes program execution to pause when it reaches a specified line of code. You can set breakpoints on one or more lines of code in your program. When execution reaches a breakpoint, the program pauses and the line of code is highlighted in the Code Editing window. While execution is paused, you can take several actions to help locate a program bug. I will describe these options soon.

TIP:  Breaking Program Execution
When you set a breakpoint in a line of code, execution pauses just before the statement on that line is executed. The statement where the breakpoint is located will be the first one executed when you continue execution.


To set a breakpoint, move the editing cursor to the line of code where you want execution to pause. Press F9 or select Toggle Breakpoint from the Debug menu. This displays a line that a breakpoint has been set on, with a different-colored background and a dot in the left margin. Press F9 or select Toggle Breakpoint again to remove the breakpoint from a line of code. You can set as many breakpoints as you need.

To clear all breakpoints, press Ctrl+Shift+F9 or select Clear All Breakpoints from the Debug menu. Note that you can’t undo this command; your breakpoints are lost and can only be reset manually, one at a time.
Another way to break program execution is based on the value of program variables rather than on specific code location. This technique will be covered in the next section.
When a breakpoint is encountered, a Visual Basic program enters break mode. You can enter break mode manually while the program is executing by selecting Break from the Run menu or clicking on the Break button on the toolbar. Entering break mode manually is useful when you realize you should have, but did not, set a breakpoint at a particular location in the code. If a Basic statement was executing at the moment, execution will pause at that statement. Quite often, however, no Basic statement will be executing; the program will be waiting for an event to occur. In this case, you cannot say “where” in your code execution halted, because the next Basic statement to be executed usually depends on the event that is received.



Previous
Table of Contents
Next






Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.