Testing and Debugging
Hi all,
I am trying to debug my .js file in VS 2005. I followed all the steps mentioned in SDK (atleat 10 times). But the program never pauses at the breakpoint when I load the gadget.
Am I missing something in this process..Please suggest...
Thanks
[274 byte] By [
Raros] at [2008-1-12]
Are you sure your gadget is getting to the code where you're trying to break? Try tossing in some alert() statements to see if they get fired. If the code's not getting called, obviously it's not going to break.
I don't really like the SDK's section on testing and debugging, so here are some modifications to what's provided in there:
- You don't need to enable debugging for "Other". That just allows you to debug in applications that embed the IE rendering engine that are not iexplore.exe (for example, this will let you debug the ad frame in your Windows Live Messenger client -- totally unnecessary for live.com gadget debugging).
- You do need to close and reopen IE. That means close all IE sessions, make sure that the iexplore.exe process has stopped, and then restart IE.
- Your local js file needs to be the same as the js file on the server where you're running the gadget from (which may or may not be localhost). If the files are different, VS won't be able to line up the breakpoints correctly.
- I don't like the "attach to iexplore.exe" method. Instead, I use the Debug menu item in the View menu of IE (only available once you uncheck "Disable Script Debugging (Internet Explorer)" and restart IE). This will prompt you with the standard debug dialog that presents you with multiple choices of debug environments, which may include a new session of VS2005, the old Microsoft Script Debugger if you have that installed, and any currently-open VS or Script Debugger sessions you may have running. From here, choose the VS session where you opened your JS file.
- Alert() debugging (normally called "printf() debugging", after the C langauge function to output a string) is not mentioned at all, but can be a very useful method to debug "big" issues (as in, "does my code even get called?").
- The Javascript error dialog/console (depending on IE or Firefox) is also not mentioned, even though these are very useful for catching errors in your code (especially syntax errors). In IE, if there's a javascript error it'll show up in the bottom-left of IE's status bar as a yellow warning icon. Double-clicking on that will show you all of the JS errors that IE has caught. In Firefox, the console is available from the Tools menu (called "Error Console" in Firefox 2.0, or "JavaScript Console" in Firefox 1.x).
- Firefox has a DOM inspector (called DOM Inspector, oddly enough) and a debugger that you can and should use when validating your gadget on Firefox. Due to security restrictions, you'll have to load your gadget on a publicly accessible web page (Firefox can't override cross-domain security, so you can't use it to run gadgets from localhost).
In your case, my first guess is that your code's not even being called. I'd start with some alert() debugging to figure out if that's the case. Otherwise, you may have an issue attaching to IE. Try restarting IE and attaching through the Debug menu in IE rather than through VS's attach to process dialog.
Thanks for the reply
All alerts are working in the javascript code...so I tried the second option that you have mentioned but I couldn't find debug option under view menu item in IE.I am using 6.0 version of explorer... Though alerts really help in debugging but to understand the flow of the sample .js files program, breakpoints really help.
Please let me know where I would find "debug" option in IE
Once you've enabled debugging support for IE (see above) and restarted IE (again, see above), there'll be a new menu option called "Script Debugger" under the View menu. Inside the "Script Debugger" submenu, you're given the option to "Open" or "Break at Next Statement". "Open" will prompt you to open a new debugger or attach an existing session. "Break at Next Statement" will do exactly as it says -- the next Javascript statement will cause IE to break into the debugger, stopping at that statement. I've generally found that the "Open" item is more useful than the "Break" item.
Hi,
I've been working at the web-development area for about 9 years now, and it seems like there's a bug with attaching the ms script debuggers to IE that has never been fixed all these years.
Symptom:
When you try to attach the debugger to IE: you got to Processes.. window:
- either the process list is empty,
- or you select the process, but the "Script" debugging is not enabled for the process,
- or you attach the debugger to the process, but the Running Documents window is empty
Workaround:
The only solution to this problem is to
- completely restart IE,
- navigate again to your web-page (or web-application page)
- attach the debugger to the process again
This is very
annoying and time consuming.
(Especially if navigating again to your web-application page involves a login-page, going through an applicative work-flow, filling in some application forms etc...)
Does anyone know what is the KB number for this problem (if there is any)?
I looked for it and didn't find it.
I have seen it with all IE versions - from IE4 to IE7
With all kind of script debuggers:
InterDev, Visual Studio, and even the script debugger that comes with MS-Office (MSE7.exe, if you have to ask).
Is there a chance MS is going to ever solve this bug?
P.S
Sometimes it is practicaly impossible to use the View --> Break at Next Statement... option of IE.
Sometimes this option crahses IE, or you want to debug exceptions that occur on page startup, so you don't have the chance to use this option before the page is loaded.
For other cases, such as dhtml-based context-menus, if you try to use this option you would just stop on an irrelevant event handler, such as the onMouseOver event of the context-menu trigger.
Perhaps your issues only apply to the Script Debugger? I've never had any of the problems you've mentioned when using Visual Studio 2005 as the debugging environment (you should be able to use one of the Visual Studio Express SKUs as well, which would give you a free alternative to Microsoft Script Debugger).
As for "break on next statement", I've never really found that to be useful. What I do instead is load the page, attach the debugger, set my breakpoints, and then reload. If you're trying to catch start-up behavior, this will allow you to do so on reload.
hi everybody,
talking about visual studio express, each time i tried to install this, i did'nt success, because the install program where turning fool and never finished it's job, i did'nt find any issues fot this, and i stopped trying to install and use virtual studio express ( i have xp media center, net framework v2, and my firewall allows the url of the install serveur ....)
Even if you know why....
thank's for all
bidochon
