Chapter 1. INSTALLING THE MICROSOFT SCRIPT EDITOR
1) From the Start Menu, if Frontpage is listed, start it, and search on the help files for "Script Debug".
If Frontpage is not in your start menu, it is possible to add only the script editor as a standalone application:
- Go to Control Panel, Add/Remove Software and open the Office Add/Remove/Repair function.
Here you can look for Office Tools, Script Editor and Debugger and set it to run from your hard disk.
This should install the editor from CAB files on your hard disk, but it may be necessary to use the Office CD as an alternative.
2) Start the Scripting Editor found under Tools/Macros/Script Editor in Frontpage. If you loaded only the script editor, the target is:
C:\Program Files\Microsoft Office\Office10\MSE7.EXE
and you can put a shortcut for it in your quickstart menu with this path.
3) Once the script editor was started, run the Web Debugging option under the Debug Menu.
This will prompt you to install the debugging features and warns that the editor will have to be restarted to use the Debugger.
Order of install is important; don't uninstall the MS Script Debugger after installing the MS Script Editor; it will mess up your registry settings and you will have to start over from scratch by first uninstalling the Script Editor and then re-installing it.
Chapter 2. USING THE MS SCRIPT EDITOR
1) Add the “debugger” keyword to any script, and it opens the script editor at that point, when the script is run in the browser. The debugger should come up when the browser issues an error alert. At first this was not working for me, but I went into the IE options panel, under Advanced and turned off “Hide scripting Errors” option, as well as turned off “Friendly Error messages”. I also had to turn on the Status Bar under the View menu. The debugger will also come up if you have a script debugger entry in IE under the View menu, like this: debugger;
Click Yes. Click Yes.
2) You may be prompted to run a regedit script the first time you try to use the debugger. Open a CMD window and run the path in the prompt, to set the proper Registry settings (notice it’s forward slash before the RegServer argument):
“C:\Program Files\Common Files\Microsoft Shared\VS7Debug\vs7jit.exe” /RegServer
NOTE: if by now, installation has not progressed as described above, try running the script above, and then logout and log back in again to be sure your machine as reloaded the registry and is now seeing your modifications.
3) Notice once the editor opens, the script is now open in the editor, and you have yellow highlighted line and pointer where the debugger keyword was used in the script. Look at the top of the window, and it lists the file currently open and the path to the file. This has saved me many times when I was editing the wrong file and could not see my changes showing up; I simply activated the debugger and found the correct page I needed to be editing!
4) There is a third way to force the debugger to open when interactively working with a page in the browser. Use the View menu, and you should see a new Script Debugger entry which has an option for “Break at Next Statement”. Once you select this, the next click on the page will force the debugger to open at whatever point in the code is issuing and handling the current event. Keep in mind, many times this will put you into an HTML page, and you will have to click on the debugger’s “Step Into” function to force the debugger to open the associated .js file if you are using JS include files.
The View menu allows entry straight into the debugger on the next click event.
5) Under the Debugger menu, there are now all the typical debugging commands available.
a) Expression evaluation is available is Quick Watch, and vars can be added to a Watch List.
b) DOM objects may be inspected in the browser document tree, as to ID, ParentId, etc and the entire DOM tree can be walked thru in it's full heirarchy.
c) Stepping thru the script is easy with Step In, Step Over; break points may be added in the usual fashion (left margin toggle click).
d) .JS files will be opened as the program execution requires (the application I am working on opens several .js files in a row)
e) A toolbar for the debugging commands exists but will need to be configured and placed in the menu bar (similar to IE).
f) All debugger commands have keyboard shortcuts that speed things along...
When the debugger first comes up, it will point out any error the browser found.
Use the Quickwatch command to evaluate a current object or variable selection, then add it to the Watch list at the bottom of the editor window. Notice breakpoints have been set by clicking on the left margin of the page.
6) Also refer to the Help file in the Script Editor for debugger commands help. It's short and sweet.
- Once you have arrived at the line throwing the error, you may inspect all variables current values by using the Evaluator window (magnifying glass on the toolbar).
- You will not be allowed to proceed in IE until the debugger is past the current break point or step. If it is stuck on an error, use the “Play” or “Stop” icon in the toolbar.
- If you are using a variable to collect HTML and then write it to the page with document.write, the HTML source will not be viewable with the view/source option in IE. It also will not be visible to the debugger, and the debugger will report it cannot preceed into the code currently being executed. If you must see the rendered HTML/JS it is possible to do a window.document.write(var) that points to a popup window previously opened for the purpose of writing into it (where “window” is a var that equals the popup window, like this: var newWin = window.open(‘’,’newwin’, 500, 500); Then use view/source in the popup to see the source of the newWin.document.write(var). You may then run the debugger in the new window.