Programming: The Microsoft Script Editor

The ‘Microsoft Script Editor’ (MSE) program is not a very well advertised application out of the suite of programs supplied in MS Office 2003.

Previously before I found about MSE’s existence, I used to code with an application called HTML-Kit to do my HTML and VBS application development. Although not a bad program, it had stability problems when saving files and would often trash the one I was working on.

MSE has got the following useful features;

• IntelliSense code completion,
• Good integration with script debugging in IE, Wscript and Cscript.

It unfortunately needs some configuration and registry editing to get the best out of it. Here is a collections of what I’ve found by googling about.

---

Installing (Finding) the MSE editor application

If you do a full install of MS Office 2003, you should find the application file at the following location. If not, run Office 2003 setup again and add ‘HTML Source Editing’ under the {Office Tools} installation category.

“C:\Program Files\Microsoft Office\OFFICE11\MSE7.EXE”

Best to make a short cut to this and place it on your desktop. Microsoft normally expects the user to start this application in MS Word {Tools/Macro/Microsoft Script Editor}. That’s dumb, it deserves its own link.

---

Enabling Just-In-Time debugging

In Internet Explorer (IE7) under {Tools/Internet Options/Advanced tab}, you can clear the checkbox under {browsing/Disable script debugging (Internet Explorer)}. It’s normally disabled by default to make life easier for web surfing where most users are not into debugging faulty things like:

Though this may now drive you mad for your own IE web surfing. There is a solution for this – surf with Firefox instead 😉

In the MSE application, set {Tools/Options} as following.

When your application crashes at a faulting line, or code execution comes across a breakpoint that you have set through MSE, you’ll be placed back into the editor with the line highlighted in yellow. If you have programmed before in VB/VBA or similar, you’ll be familiar in what you can do here – single step, step over, watch variables – it’s a lifesaver 🙂

---

Debugging WSH and VBS scripts

The environment is set up by default to debug scripts running inside the Internet Explorer process. However, you can choose to use the wscript.exe and cscript.exe interpreters by selecting “view/open with” and adding those alternative choices to use instead.

For instance, add the command line ‘wscript.exe //x’ with a friendly name of ‘wscript (start in debugger)’ – and ‘open’ the application from this dialog rather than clicking the run button on the toolbar (which targets IE).

---

Finding more information

There are lots of other websites and blogs about this tool. Here is one
http://www.jonathanboutelle.com/mt/archives/2006/01/howto_debug_jav.html

Advertisement

Programming: Missing WScript namespace?

Came across this on usenet. Copied here so I’ll not lose it!

“WScript is an object exposed by the WScript and CScript script hosts. Since the
Microsoft Script Control is a different host, it does not have that internal
method available to it.

You can work around that by adding the WScript namespace to a script control
instance, assuming that the original host creating the instance is itself a
WSH-hosted script.

If your script control is referenced as sc, then once you initialize it you can
add WScript using the native name using the Script Control’s AddObject method,
like this:


Sc.AddObject “WScript”, WScript