| |
Quick References
Features
Partners
|
|
|
|
|
A Beginner’s Guide to Using Microsoft Script Debugger
As any code writer knows, the introduction of errors during development is
almost inevitable. One of
the most frustrating aspects of the code-writing process can be the detection
and correction of these "bugs." Microsoft Script Debugger is a utility that
extends Microsoft Internet Explorer 4.0, 5.0 and Microsoft Internet Information
Server (IIS) 4.0 to assist the Web developer in debugging scripted HTML pages
(.htm, .html, and .asp files).
Script Debugger can be used to debug both client-side and server-side
scripts. In this tutorial, we will focus only on the process of using Script
Debugger for debugging client-side scripts, so the IIS interface will not be
covered here. Client scripts consist of statements (typically written in
VBScript or JScript) that appear on the HTML page and are executed either
when the document is loaded into the browser, or in response to an event such
as a button click. We will demonstrate, with a simple example, everything you
need to get up and running with client-side debugging with Script Debugger.
Before we begin, make sure you are running Microsoft Internet Explorer
version 4.0 or 5.0. Also, be sure that debugging has not been disabled in
the browser. To check this, open the `Internet Options’ window (under `Tools’
menu in IE5, or `View’ menu in IE4), and then select the `Advanced’ tab. The
`Disable script debugging’ box under `Browsing’ should not be checked.
Next you must determine whether or not Microsoft Script Debugger is
installed on your system. Look for `Script Debugger’ under the `View’ menu
in Internet Explorer. If `Script Debugger’ is there, choose `Open’ from the
pullout menu, to see which script debugger is installed. If you do not have
any script debugger at all, or if you prefer Microsoft Script Debugger instead
of an existing debugger, you will need to download it from:
http://msdn.microsoft.com/scripting/debugger/dbdown.htm
If Microsoft Script Debugger already exists on your system, check its version
number (with Microsoft Script Debugger open, choose `Help’ and then `About
Microsoft Script Debugger’). If you are running under Windows 9X and have the
debugger version 1.0a installed, it is recommended that you revert to
version 1.0, due to problems in version 1.0a. Be advised that this download
proceeds in a non-standard fashion, and read the documentation at this site
very carefully in advance.
There are several ways to start the debugger: manually, automatically through
the browser, and programmatically through the code. We’ll touch on all of these
methods in this tutorial, so let’s begin by composing a simple HTML page that
will need some debugging. We’ll write an HTML page about how easy it is to use
Microsoft Script Debugger. Our document will contain a header and some JScript
code to display the message "Using Microsoft Script Debugger is as easy as 1 2 3!"
<html>
<head>
<title>Using Microsoft Script Debugger is Easy!</title>
</head>
<body>
<h1>Using Microsoft Script Debugger is Easy!</h1>
<script language="JScript">
document.write ("Using Microsoft Script Debugger ")
document.write ("is as easy as)
for (var i = 1; i <= 3; i++)
{
document.writeln (" " + i)
}
document.writeln ("!<BR>")
</script>
</body>
</html>
The observant reader may have already noticed that a terminating quotation
mark is missing from one string in our hastily typed document. Unknowingly,
we load the page into our browser, and instead of our enthusiastic exclamation,
we are presented with the following screen (or something very similar).
Choose `Yes’ to start the debugger. Script Debugger begins to execute and
displays the page that triggered the error.
Unfortunately, in this instance, the cursor does not appear directly on top
of the offending string, or even on the pertinent line! Having been informed
that the problem is an unterminated string constant, however, we quickly discover
the source of the error, and know exactly how to fix it.
Note that the copy of our source code that Script Debugger displays is
read-only. To fix our source, we must be able to edit the file, and we can do
this directly from Script Debugger by opening a local copy of the file.
(Alternatively, any other editing mechanism can be used at this point to edit
the file.) To demonstrate how to do this via Script Debugger, we choose `Open’
from the debugger `File’ menu, and open the file containing the HTML source code.
We edit and save the file using the `File’ and `Edit’ menus on the Script
Debugger. Then we return to Internet Explorer and refresh the document, which
is now displayed without incident.
Feeling enthused by our success, we decide to print out our message three
times rather than just once. We edit the opened copy of our document accordingly
and save it.
Thinking that our problems are over, we close the debugger. We then return to
Internet Explorer and refresh the document. To our surprise, the result looks
exactly like it did last time.
In confusion, we will probably re-save the source code, and refresh Internet
Explorer several times, before coming to the unavoidable conclusion that we are
faced with a logic error in our code. Unlike syntax errors and runtime errors,
the browser does not detect logic errors, so we are not offered an automatic
entry into the debugger. We have a couple of options at this time. We could edit
the source HTML page, and place a `debugger’ statement directly into the JScript
code at the point at which we would like debugging to start. This invokes the
debugger programmatically. We could also, from the browser’s `View’ menu, select
`Script Debugger’ and then `Break at Next Statement.’ If we do that, we then
need to refresh the browser window, after which the debugger will begin running,
and will break at the first line of code in the document. A third option is to
select `Script Debugger’ from the browser’s `View’ menu, and then `Open.’ Let’s
take this third option.
Note that only a few options on the debug toolbar are highlighted now. This
is because all of the code on the current page has completed execution. We will
need to step through our code to try to figure out what is going on, so click the
 (Break at Next Statement) option to
cause the debugger to break at the next statement. Then return to the browser and
refresh the document.
Suspecting that the problem occurs in the second `for’ loop, we decide to set
a breakpoint there. To do this, place the cursor over the line containing the
second `for’ loop, and set the breakpoint by clicking the
 (Toggle Breakpoint) shortcut on the
toolbar.
Now click the  (Run) toolbar shortcut
to resume execution, which stops again when it reaches the breakpoint.
Open the command window by clicking the
 (Command Window) toolbar shortcut. In
the command window, you can type in script commands (using the current scripting
language) that will be immediately executed. You can also query variable values,
call objects and procedures, view debugging output and evaluate expressions. To
find out the current value of the variable `i’, type the variable name into the
command window, and press return. The value appears on the following line.
Step through the code one statement at a time, by repeatedly clicking the
 (Step Into) toolbar shortcut, until
execution returns to the outer `for’ loop.
Check the value of the variable `i’ again in the command window.
At this point, we realize that we have used the same variable as a counter in
both `for’ loops. In the command window, we manually change the value of this
variable by entering the statement `i = 2’.
To test the output of this change, remove the breakpoint we have set. To do
this, place the cursor over the line and click the
(Toggle Breakpoint) toolbar shortcut.
We can also click the 
(Clear All Breakpoints) toolbar shortcut to remove all breakpoints. (Note that
refreshing a document also clears all breakpoints.) Click the
(Run) toolbar shortcut to resume
execution. We now see in the browser what we would expect in light of the logic
error in the code, and having manually set the value of the counter.
We have now identified the bug in our code, and know how to fix it. At this
point, we can choose the  (Stop
Debugging) toolbar shortcut to stop debugging.
This brief example illustrates some of the most useful features of the
debugger. Besides stepping one statement at a time, Script Debugger also allows
us to step over procedures by clicking 
(Step Over). In this situation, the procedure is executed, but the debugger does
not pause execution again until the procedure terminates. To stop stepping
through individual lines in a procedure, choose
 (Step Out). In this case, the debugger
pauses execution again at the next statement following the procedure.
We can also display the call stack 
(Call Stack) and navigate to nested procedures. This can help you trace the
course of execution through procedure calls. You can navigate to another
procedure to set breakpoints, query values, etc., but this does not change the
currently executing line or the current context. If more than one thread is
running, each will have its own call stack displayed in the window. Double-click
a procedure in the list to see the place in the script where it was called.
Choosing  (Running Documents) will
open the `Running Documents’ window, which lists all the open documents available
for debugging. Double-click a document name to open it. You can also right-click
the name of a document to break at the first statement in that document.
A final feature that may be of great benefit when debugging a large document is
setting bookmarks. Pressing CTRL+F2 toggles a bookmark on the current line. To
navigate from bookmark to bookmark, press F2 to move forward, or SHIFT+F2 to move
backward.
This concludes our introductory tutorial on Microsoft Script Debugger. We hope
that this is sufficient to get you up and running. Experiment, explore, and
above all, have fun!
|
|
|
|
