dougr
asked on
Debugging Techniques
I have a couple of questions re debugging a program and finding errors:
First Some Background:
I often use Debug.Print statements throughout the program to help monitor the program flow pattern. This enables me to quickly narrow down on the code which causes the error.
I also use an Error Handler Function which traps program errors and displays:
Err.Number
Err.Description
Screen.ActiveForm.Name
Screen.ActiveControl.Name (if one exists)
Several Status Flags *
Approximate Line Number *
*Note: The Status Flags and Line Number displays are determined by various Flag and Line Number variables which are set at critical points throughout the program.
In the error handler I also use a vbYesNoCancel MsgBox to determine the disposition of the error. I can stop program execution immediately, or return to the Main Program Menu, or try to continue program execution from where the error occurred.
Question 1:
In the development environment, my Debug.Print statements, while extremely useful in tracing program flow, produce hundreds of lines in the Immediate Window. So each time I run the program I have to manually clear the Immediate Window (by Highlighting and Deleting all lines)
Is there a way to CLEAR THE IMMEDIATE WINDOW by some code at the beginning of the program so that it is always cleared when the program starts running?
Question 2:
Sometimes the error handler gets in the way of tracing the error because it clears the error before you can identify the exact place where the error occurred. If you go to "Tools - Options - General" in the development environment, you can click a button which enables a "Break on All Errors" option. However I cannot use this option because I have some DELIBERATE errors in my program which I use to trigger various choices. So my question is this: Can you turn the "Break on All Errors" option ON and OFF programatically at various critical points in the program. If so what is the code?
dougr
First Some Background:
I often use Debug.Print statements throughout the program to help monitor the program flow pattern. This enables me to quickly narrow down on the code which causes the error.
I also use an Error Handler Function which traps program errors and displays:
Err.Number
Err.Description
Screen.ActiveForm.Name
Screen.ActiveControl.Name (if one exists)
Several Status Flags *
Approximate Line Number *
*Note: The Status Flags and Line Number displays are determined by various Flag and Line Number variables which are set at critical points throughout the program.
In the error handler I also use a vbYesNoCancel MsgBox to determine the disposition of the error. I can stop program execution immediately, or return to the Main Program Menu, or try to continue program execution from where the error occurred.
Question 1:
In the development environment, my Debug.Print statements, while extremely useful in tracing program flow, produce hundreds of lines in the Immediate Window. So each time I run the program I have to manually clear the Immediate Window (by Highlighting and Deleting all lines)
Is there a way to CLEAR THE IMMEDIATE WINDOW by some code at the beginning of the program so that it is always cleared when the program starts running?
Question 2:
Sometimes the error handler gets in the way of tracing the error because it clears the error before you can identify the exact place where the error occurred. If you go to "Tools - Options - General" in the development environment, you can click a button which enables a "Break on All Errors" option. However I cannot use this option because I have some DELIBERATE errors in my program which I use to trigger various choices. So my question is this: Can you turn the "Break on All Errors" option ON and OFF programatically at various critical points in the program. If so what is the code?
dougr
The technique you use in 2 seems a bit confused. Error handlers should not be used to control program flow. Can you develop it further. Otherwise there is the run to this point, CtrlF8 I think.
Forcing an error is a way to check an error handling routine, but as a rule, it doesn't serve to any other purpose.
¿Why d'you force an error into your program?
¿Why d'you force an error into your program?
ASKER
To: vikiing and Llandr
You are right, forcing an error may just be a sloppy program technique on my part. I used this technique a lot in the MicroSoft DOS Basic (Professional Edition Version 7.1) where there were multiple modules and overlays and the 640 k memory limit. I would write an error handling routine in the opening module which caused a default to an opening menu. Then, no matter how deep into sub-modules, subroutines and overlays I could create a deliberate error (i.e. take the square root of minus 1) to force a return to the opening menu without having to go back through the tree of Subroutines. I would let the program close the Subroutines and close the various open files without having to think about it. (Yes I know - sloppy!).
However, having admitted to sloppy programming, there are still some cases where I use deliberate errors during the development stages of a program. Sometimes I will write incomplete code segments as I dummy up the program structure in the early stages of a program. There may be parts of the program that are supposed to open up files which don't exist yet, or to access directories which I haven't yet been created. In this case I will often use the error which is generated to temporarily bypass that code segment (usually with a message which says "Not Written Yet" or something to that effect).
Also, when supplying a program to a client, certain files and directories are created "on the fly" to the client's specifications, where the program does not know the names in advance. Sometimes the error flags the non-existence of a required directory and prompts the customer to create it.
Sometimes my development environment is so different from the cutomer's that, for testing purposes, I need to use error handling to allow the program to run on my machine without having to duplicate the files and directory structures which exist on the cutomer's machine.
I guess I may be guilty of sloppy programming by sometimes using error generation as a shortcut to writing more sophisticated code. However I would still be interested in your comments on my 2nd question. Does anyone else use these techniques, or am I away out in left field?
dougr
P.S. Does anyone have further comments on my question 1 and on janeausten' addendum to it?
You are right, forcing an error may just be a sloppy program technique on my part. I used this technique a lot in the MicroSoft DOS Basic (Professional Edition Version 7.1) where there were multiple modules and overlays and the 640 k memory limit. I would write an error handling routine in the opening module which caused a default to an opening menu. Then, no matter how deep into sub-modules, subroutines and overlays I could create a deliberate error (i.e. take the square root of minus 1) to force a return to the opening menu without having to go back through the tree of Subroutines. I would let the program close the Subroutines and close the various open files without having to think about it. (Yes I know - sloppy!).
However, having admitted to sloppy programming, there are still some cases where I use deliberate errors during the development stages of a program. Sometimes I will write incomplete code segments as I dummy up the program structure in the early stages of a program. There may be parts of the program that are supposed to open up files which don't exist yet, or to access directories which I haven't yet been created. In this case I will often use the error which is generated to temporarily bypass that code segment (usually with a message which says "Not Written Yet" or something to that effect).
Also, when supplying a program to a client, certain files and directories are created "on the fly" to the client's specifications, where the program does not know the names in advance. Sometimes the error flags the non-existence of a required directory and prompts the customer to create it.
Sometimes my development environment is so different from the cutomer's that, for testing purposes, I need to use error handling to allow the program to run on my machine without having to duplicate the files and directory structures which exist on the cutomer's machine.
I guess I may be guilty of sloppy programming by sometimes using error generation as a shortcut to writing more sophisticated code. However I would still be interested in your comments on my 2nd question. Does anyone else use these techniques, or am I away out in left field?
dougr
P.S. Does anyone have further comments on my question 1 and on janeausten' addendum to it?
Regarding q.2: as far as I know, you can't force the flag "Break on all errors" at run time.
Deer dougr
The method you are using is wrong from the basic. You have to build your functions to return boolean, so you can detect if the function you tried to excute done it's perpuse. For Example : Public Function CheckDir(CheckThisDir as String)As Boolean
On Error Goto Err_CheckDir
if Len(Dir(CheckThisDir))<=0 Then Goto Err_CheckDir
CheckDir = true
Exit_CheckDir:
Exit Function
Err_CheckDir:
CheckDir = False
Resume Exit_CheckDir
End Function
For general information you asked for...
You can't access any of the IDE from your project.
For accessing the IDE you must be in design time.
The method you are using is wrong from the basic. You have to build your functions to return boolean, so you can detect if the function you tried to excute done it's perpuse. For Example : Public Function CheckDir(CheckThisDir as String)As Boolean
On Error Goto Err_CheckDir
if Len(Dir(CheckThisDir))<=0 Then Goto Err_CheckDir
CheckDir = true
Exit_CheckDir:
Exit Function
Err_CheckDir:
CheckDir = False
Resume Exit_CheckDir
End Function
For general information you asked for...
You can't access any of the IDE from your project.
For accessing the IDE you must be in design time.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
To: peterdc
Sory I took so long to evaluate the answer, but Christmas got in the way.
I don't seem to be getting any encouraging answers to my 2 questions, so in the absence of a better way, your idea of clearing 199 lines in the immediate window seems to be a decent compromise on question #1.
Apparently the immediate window can hold approx 200 lines. Do you know of any to increase this number of lines so that more debug history can be stored?
dougr
Sory I took so long to evaluate the answer, but Christmas got in the way.
I don't seem to be getting any encouraging answers to my 2 questions, so in the absence of a better way, your idea of clearing 199 lines in the immediate window seems to be a decent compromise on question #1.
Apparently the immediate window can hold approx 200 lines. Do you know of any to increase this number of lines so that more debug history can be stored?
dougr
Sorry I don't know of any way to increase this line limit. However if you terminate your debug statements with a semicolon you can make better use of each debug print line. Might not be so easy to read, though there will be a space between each debug print, but at least you are storing more debug history.
afaik, there's no way to clear the immediate window thru code. the best way i know is simply pressing ctrl-a in the immediate window (this automatically selects all), then del.
i do hope someone out there knows an answer to this, i'm very interested in learning it myself.
happy holidays!