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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.