Assegnate 1 su 5 stelle

di MarkusProkott il Marzo 26, 2010 · link permanente

I'm know a lot of programming languages and also a lot of debuggers, including IE's. And while this one may not be completely useless or unusable, it's certainly and BY FAR the worst one I ever saw. It's unintuitive, unergonomic and buggy (and I haven't Firebug installed during testing this). So I rate this 1 star: Bad.

For example, one pop-up item for a file entry in a list says: "Find URL", and this just opens the file in the source code section. Why not just calling this "Open URL" as usual in 99% of all the software in the world!!!??? I firstly thought this would open some search dialogue and thus didn't click it. I needed to read a tutorial to learn what this does.

Especially this tool is rather useless for debugging Chrome URLs. For this purpose you have to switch of the "Exclude browser files" option. But then--besides the few JS file of yours you ACTUALLY want to get debugged--all the uninteresting browser background files are debugged simultaneously.

Every mouse move you do within the browser area may trigger the debugger. Sometimes, you cannot even reach the reload button to reload the URL you really want to debug. I tried to disable debugging of all the other files MANUALLY by selecting each of them and switching their debugging off. But then, although my files were NOT switched off, they are not debugged any longer. I couldn't get them to be debugged either. Instead some of the files for which I explicitly DISABLED debug automatically RE-ENABLE their debugging again, triggering the debugger again for errors I'm completely uninterested in and popping these files up in the source code section, disturbing my view. And not enough, the debugger by itself also CLOSES(!) my files within the source code section without any reason or request from me. I had to reopen but any breakpoint got LOST!

Lastly, I have to agree to what someone wrote here earlier: "However I haven't been able to do a simple set-a-breakpoint->run->step-trough-code use case." (ciacob on August 1, 2009)

Moreover, when I finally got the debugger to stop at a breakpoint, there's been no obvious way to make the script just run from there to the next encounter of a breakpoint. You have to "step" instead to "run". Maybe there is a way, but it's really not obvious. When I pressed e.g. "Step over", the debugger stepped into the file "browser.xml" (which also popped up in the source code section), although it was EXPLICITLY marked in the "Loaded Scripts" section as not-to-be-debugged!!! If I instead clicked "Continue" I would never see my breakpoint again, since from then the script is run without regard to any breakpoint it contains. Thus, there is for example no way for observing a breakpoint within a for-loop for every cycle of the loop, except (MAYBE, but I don't see how) by stepping each line in the for-loop for each cycle of the loop.

I see from the other reviews that many people find this tool useful. I cannot understand why and I really cannot recommend this piece of software. Moreover, I explicitly recommend NOT to install it, if you want it for the debugging of scripts of Chrome URLs. Unfortunately, you'll have to use alert-boxes to debug these scripts.