Visual Studio: Enable / Disable IE Script Debugging Tool

Rocky: There has already been two attempts on your life.
Bullwinkle: Don't worry, we'll be renewed.

If you are like me, you are always keeping your eye out for shortcuts and ways to make your life easier. One of the little annoyances of working with Visual Studio .NET is that it has no option to turn Client Script Debugging on or off – you have to open up Internet Explorer, go to Tools/Internet Options/Advanced and either check or uncheck the checkbox option.

All this checkbox does is control a Registry entry, so why not just make a little .vbs script and register it as an External Tool in Visual Studio?

The steps to do this are very simple. But first, you need to find out what Registry Key has your value.

The key is located at HKEY_USERS\XXXXXX\Software\Microsoft\Internet Explorer\Main\ where “XXXXXX'” could either be “.default” or one of the machine user identities such as “S-1-5-19”. Once you have identified where your actual “Disable Script Debugger” key is located, you can modify the short script below, and save it as “IEScriptDebug.vbs” in a convenient folder.  You should also make a second batch file, “IEScriptDebug.bat” that will run this, since Visual Studio doesn’t like to configure .vbs files as executables (even though they are), preferring .bat files instead.

Here’s the script:

Option Explicit
' NOTE you will need to find the HKEY_USERS\XXXXXX\Software value of "XXXXXX" for your machine.
' where this key is located; It could be \.Default\. On this machine it is \S-1-5-19\
Const cHKU = "HKEY_USERS\S-1-5-19\Software\Microsoft\Internet Explorer\Main\"
Const cDSD = "Disable Script Debugger"
Dim objWSH
Set objWSH = WScript.CreateObject("WScript.Shell")
Dim strWSH
strWSH = LCase(objWSH.RegRead(cHKU & cDSD))
Dim strMSG
strMSG = cDSD & " = " & strWSH & vbCrLf & vbCrLf & "Toggle this value?"
If MsgBox(strMSG,vbYesNo,cDSD) = vbYes Then
If strWSH = "no" Then
objWSH.RegWrite cHKU & cDSD, "yes"
Else
objWSH.RegWrite cHKU & cDSD, "no"
End If
MsgBox cDSD & " = " & objWSH.RegRead(cHKU & cDSD),vbInformation,cDSD
End If
Set objWSH = Nothing

 

Once you’ve got your .vbs and .bat file saved, in Visual Studio, all you need to do is choose “Tools/ External Tools” and add it:

 

Now whenever you want to toggle Script Debugging, Just hit “Tools / Script Debugging” in Visual Studio and you are good to go!

 

DOCTYPE – or DUCT TAPE?

Today a fellow developer who works offsite sent out an email asking for help. He is apparently using a javascript “virtual keyboard” to help with accessibility on an ASP.NET app he’s working on.  In the sample “.htm” page, it seems to work great. But when he added everything to a new .ASPX page, the virtual keyboard jumps down in the page when invoked,  and this gets worse as you add more breaks to move the target textbox down the page. He states he knows  it’s “just some IE bug, but I am going nuts trying to find it”.

I opened the app. The .htm page works great. In the .aspx page, just as he describes, instead of the virtual keyboard rendering just below the input box, it renders at least 2 or three lines below where it is supposed to appear. Yet, all the code, javascript, CSS – is IDENTICAL! Or is it?

In the .Htm page, the DOCTYPE Declaration specifies XHTML STRICT. The default DOCTYPE from the .ASPX page is XHTML TRANSITIONAL. Yep, it can sure make a difference. Its “Not a Bug” – IE is simply doing its best to follow what you told it!

This CSS will also help IE play nice:

<style type="text/css">
html, body
{
height:100%;
overflow: auto;
}
</style>

The moral of the story is, “Don’t DuctTape your DocTypes!”