Today I have a simple debugging tip.
Sometimes when you have an obscure bug, you need to answer the question “is my code even getting executed?” Often you can find that really obscure bugs are caused simply by a bad conditional, a typo, an unexpected exception, or some other flow-control issue that bypasses your code altogether.
Whilst you can use an interactive debugger such as Microsoft Visual Studio for tracking down some of these things, debuggers aren’t always available (eg, if you are on a hardware emulator), and if the bug is timing-related then they hamper your ability to reproduce the problem. Worse still, if your bug is in a declarative timing section (rather than in a script file) there’s currently no way to debug that at all.
So you need something a bit less impactful.
In the good old days of C programming, people used to use “printf debugging” to display a message on the console indicating that a particular line of code had executed, and possibly to show the value of a variable. In the web world, this was changed to “alert debugging” where a popup window was used to the same effect.
For HD DVD, I like to use “red box debugging”. Basically I create a big red div in my markup file and set style:display=”none”. Then at the point in my script where I want to “prove” that it gets executed or not, I simply say document.whateverTheIdIs.style.display = “auto” and see if the red box appears. And if your bug is timing related, you simply has a cue that does a <set style:display=”auto” /> and similarly proves (or disproves…) that your program is working as planned.
That’s all J