Re: What do people use Venkman for?
Richard Kramer <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.jsdebugger |
|---|---|
| Organization | Another Netscape Collabra Server User |
| Message-ID | <[email protected]> |
7stud wrote: >>>Secondly, doesn't having to step through all the variable declarations >>>essentially make Venkman useless for large scripts? Someone might have > > to > >>>step through 50 variable declarations interspersed in 1,000 lines of > > code > >>>just to get to the start of the script? >> >>Breakpoints are your friend. >>Use them to stop at the place you're interested in. >> > > > How does setting a breakpoint help? If someone were to set a breakpoint on > the first line of code, Venkman would stop there, and then the person would > still have to traverse 50 variable declarations in 1,000 lines of code > before getting to the start of execution. How does setting a breakpoint > allow you to skip having to step through all the variable declarations? In > other words, if you set a breakpoint at line 1, how does Venkman know > whether you want to follow it as it hunts for all the variable declarations, > or you want to skip past all that and start with execution at line 1? > Try this: In Venkman, enable "stop for errors" and "stop for exceptions" in the debug pull-down. Check off "Exclude Browser Files" and uninstall the LiveHttpHeader extension if it was insalled. In the browser, load the page to be tested. If there are syntax problems with the javascript, Venkman will usually open at a point where you can see the problem. Otherwise, you will see your page in the browser. (Certain errors may not cause Venkman to trigger, but the Javascript console in the browser's Tools menu will be of help.) To debug a function for example, in Venkman, look in the Loaded Docs window for the file of interest, click on the + thingy, then double click the function name. After a significant delay, the source should show in the Source Code window. If you toggle Pretty Print, you will see only the function or you will see the whole file. Set a breakpoint (or more) by clicking any "-" in the gutter. You can set breakpoints, or future breakpoints, which will usually be remembered if you reload the page (to check an onLoad event, for example) Instead of setting a breakpoint, you can click the red X Stop so that it shows an elipsis. Doing so has the effect of causing Venkman to fire at the next javascript statement, such as when you click a button. If you need to trace execution during the file loading phase, double click _toplevel_ of the file in the loaded docs tree. In the source window, set a future breakpoint in the gutter by the light bkue area associated with the <script> tag and reload the document. Instead of single stepping throught gobs of uninteresting code, scroll down in the source window to a line of interest, right click and select "run to line." The browser will be dead if the green Continue in Venkman is lit. Hit Continue or F5 to get past that. I find F11 and F12 more convenient if there is a lot of single stepping or stepping over to be done. Richard