Microsoft Script Debugger
The Microsoft Script Debugger is a free utility available from Microsoft’s Web site. The results list comes up with Script Debugger for Windows NT, 2000, XP.Click that link and click the Download button. Run the installation program and then restart Internet Explorer.
Notice a new menu item that appears under the View menu called Script Debugger. This provides options for running the debugger.
You can run the Microsoft Script Debugger in a number of ways. First, you can open it directly by selecting View
When the code encounters the debugger command, code execution is halted and the debugger is opened (making it very similar to the Break At Next Statement option).
The Microsoft Script Debugger is actually made up of a single window with three smaller utility windows.
The second utility window is labeled Call Stack and, as you might assume,this displays the call stack up to the current breakpoint in the code. Double-clicking on an entry in the Call Stack window brings up the source code for the function.
When you hit the Enter key, the line of code is evaluated and the value displayed.
Breakpoints and stepping
To set a breakpoint in your code,load the file into Internet Explorer and then open the debugger. Find the file you want to debug in the Running Documents window and double-click it. Then, go to the line of code you want to stop on and click the Set Breakpoint button (the white hand) in the toolbar. The line is then highlighted in yellow, and a yellow arrow is placed in the margin. Then, go back and reload the page in Internet Explorer and run the command; execution stops at the specified point and the debugger takes over.
At that point, you can do several things. If you want to step through the code, you can use the Step Into (which executes the code line by line, stopping after each one), Step Over (which doesn’t follow code execution into functions),and Step Out (which moves execution outside of the function to the place where the function was called).
If you want to continue normal execution of the code until the next breakpoint,click the Run button; if you want to stop debugging altogether, click the Stop Debugging button to prevent any further stoppage in the code’s execution.
Venkman – Mozilla’s debugger
The Mozilla debugger, Venkman(named after the character Peter Venkman of theGhostbusters movies), is a free utility for Mozilla-based browsers (including Firefox). At this address, you find a list of all the Venkman builds.Click the Install link next to the latest version. You are prompted to continue the installation because Venkman is an unsigned Mozilla plugin.Click Install Now. Restart the browser and you notice a new entry under the Tools ➪ Web Development menu.
You can also use the debugger command in your code. It works with Microsoft’s Script Debugger. Any time you include the debugger command, the debugger opens up at that line of code and stops execution.
Unlike Internet Explorer, Mozilla never asks you if you’d like to debug an error.
The Venkman window is much more complicated than the Microsoft Script Debugger, but also a lot more powerful.
The window is made up of several smaller windows (or views) containing various information about the scripts you are inspecting. Each view is made up of several common components, as illustrated in figure.
Each view consists of the following:
The entire interface is completely configurable to allow you to rearrange, resize, and otherwise manipulate the Venkman window to best suite your needs.
Eight views are available in Venkman, and each is just as powerful as the last:
The Loaded Scripts pane
For each file in the Loaded Scripts pane, you can determine whether the script contained within it should be debugged or not.Just right-click on the file and select File Options. A submenu appears giving you complete control over debugging and profiling.
If you don’t want to debug any code in the file,click Don’t Debug Contained Functions(by default, all functions are debugged). This menu also allows you to prevent debugging of eval() or timeout code by selecting Don’t Debug Eval/Timeout.
By default,Venkman tries to show only the files you have loaded into the browser; however,it is capable of loading all files that the browser loaded behind the scenes in addition to your own. You see all the loaded browser files by unchecking Exclude Browser Files on the context menu. Also by default, the pane only shows one instance of each file that is loaded; you can override this by unchecking Exclude Duplicates on the context menu.
Each function in the Loaded Scripts pane also has a certain level of control. By right-clicking on the function, a context menu similar to that of the file is presented. Under Function Options, you can click Don’t Debug to force the debugger to ignore that one function instead of the entire file.This gives you an optimal level of control over the debugging process.
Among the several ways to set up breakpoints in Venkman,the fastest and easiest way is to double-click on the file containing the script to debug.When that code shows up in the Source Code view, scroll down to the line on which you want to set the breakpoint on and click the left margin next to the line (a dash is next to any line where a breakpoint can be set).You see a B,meaning that a hard breakpointhas been set, or an F, meaning that the debugger could only set a future breakpoint .A future breakpoint is created when the script has already been unloaded from memory, but it becomes a hard breakpoint the next time the script is loaded (if you reload the browser,for example).
You can always create a future breakpoint by double-clicking in the left margin instead of single clicking, but you cannot force a hard breakpoint if, after one click,a future breakpoint is set.
The second way to set a breakpoint or future breakpoint is to use the command-line interface and the /break command (to set a hard breakpoint) or /fbreak command (to set a future breakpoint). Both commands take two arguments: the filename to set the breakpoint in and the line number to set the breakpoint on. For example:/break ThrowExample.htm 7
This command sets a breakpoint on line 7 in the file matching ThrowExample.htm. For the filename, you don’t need to type in the full path or even the full filename. Just a few characters are needed to uniquely identify the file among all the files that are loaded into Venkman. Just the first few letters of the filename are usually enough:/break Thr 7
After a breakpoint has been created (using either method), it is stored in the Breakpoints view under the filename.Hard and future breakpoints are stored separately, so you may see two different entries for the same file. Only hard breakpoints can be viewed by function name and line; future breakpoints are listed only as filename and line number.
You also have many options to clear a breakpoint. First, you can click on the B or F in the left margin until it turns back to a dash. You can also right-click on the Breakpoints view to call up a context menu where you can select whether to clear a hard breakpoint,a future breakpoint, all hard breakpoints, or all future breakpoints.
The last method is to use the command line interface again and use the /clear command (to clear hard breakpoints) or the /fclear command (to clear future breakpoints).These commands accept the same arguments as /break and /fbreak: the filename and the line number to clear. Once again, the full filename isn’t necessary, so the following two lines accomplish the same thing:
You can clear all hard breakpoints using the /clear-all command and all future breakpoints using the /fclear-all command.
Stepping through the code
As with breakpoints,you have numerous ways to step through your source code.The simplest way is to use the debug toolbar, which is prominently displayed at the top of the Venkman window.
The debug toolbar is made up of five buttons: Stop, Continue, Step Over, Step Into, and Step Out.The Stop button stops the currently active script without executing any further lines of code.If no code is being executed, three white dots appear over the Stop button to indicate that the debugger is not currently running any code. The Continue button resumes executing the script and continues until the natural end of the script or a breakpoint is encountered. The last three buttons are standard Step Over, Step Into, and Step Out commands.
All these actions can also be performed in the Interactive view by using the commands in the following table.
When code execution is stopped on a particular line, that line is highlighted in yellow in the Source Code view.Additionally, the function containing that line is displayed with a yellow arrow in the Call Stack view .
The Call Stack view always has a generic __toplevel__ item to represent the global scope from which the first function was called.
One of the unique features of Venkman is its capability to set up variable watches. Watches literally watch variables for changes in their values and display them in the Watches view.
To add watches, you can select a variable in the Local Variables view, right-click, and select Add Watch Expression.You can also use the /watch-expr command in the Interactive view to do the same thing:/watch-expr variable_name
Adding a watch adds a variable into the Watches view. The Watches view behaves in the exact same way as the Local Variables view, displaying the value of each variable when available and enumerating all properties of each object.
One of the unique features of Venkman is its profiling capability. If you turn on profiling, Venkman begins keeping track of each function, how many times it’s called, and how long each call takes.
You can turn profiling on and off by clicking the Profile button on the toolbar. A green checkmark appears on the Profile button when Venkman is profiling; no checkmark appears when it is not profiling.
After Venkman is in profiling mode, run your script. When you are satisfied with your tests, select Profile ➪ Save Profile Data As. You are presented with a Save File dialog where you can save the profile data to view later.
By default, the dialog suggests you save the file in HTML format. This is a bug; you should save the file as plain text.
When you profile your script,each function gets a section in the file that looks like this:
Each section begins with the location of the file containing the function and is followed by each function contained in the file. Each function is displayed with the following:
This information is incredibly useful for detecting bottlenecks in your code.
You can also determine which functions are profiled.To set an entire file so that it won’t be profiled, right-click on the file in the Loaded Scripts view and select File Options ➪ Don’t Profile Contained Functions. If you want to disable profiling for a single function, right-click on the function in the Loaded Scripts view and select Function Options ➪ Don’t Profile.
Java Script Related Tutorials
|Adv Java Tutorial||Core Java Tutorial|
|Java-Springs Tutorial||Java Servlets Tutorial|
|EJB(Enterprise JavaBeans) Tutorial||JavaServer Faces (JSF) Tutorial|
|Java Swing Tutorial||Java Tutorial|
|JavaMail API Tutorial||Java 8 Tutorial|
|Java XML Tutorial||Java Bean Utils Tutorial|
|The Java Debugger (JDB) Tutorial||Java.math Package Tutorial|
Java Script Related Interview Questions
|Java Script Interview Questions||Adv Java Interview Questions|
|Core Java Interview Questions||Java-Springs Interview Questions|
|Java Servlets Interview Questions||EJB(Enterprise JavaBeans) Interview Questions|
|JavaServer Faces (JSF) Interview Questions||Java Swing Interview Questions|
|Java 8 Interview Questions||Java XML Interview Questions|
|JavaFX Interview Questions||The Java Debugger (JDB) Interview Questions|
Java Script Related Practice Tests
|Java Script Practice Tests||Adv Java Practice Tests|
|Core Java Practice Tests||Java-Springs Practice Tests|
|Java Servlets Practice Tests||EJB(Enterprise JavaBeans) Practice Tests|
|JavaServer Faces (JSF) Practice Tests||Java 8 Practice Tests|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.