![]() Basically, it’s a hierarchy of the last functions called. To the right is something traditionally called a callstack, and it’s extremely useful. The next time you run your program, your breakpoint will be re-enabled unless you remove it. The two buttons below on the toolbar are for managing breakpoints ( you can end up with a lot of them quickly! ), as well as to mute a breakpoint, which causes it not to fire DURING THIS DEBUGGING SESSION. When you are done with a breakpoint, you hit the resume button to continue your program execution. The toolbar on the left hand side can be used to resume program execution, stop completely, or to run from the beginning ( currently grayed out ). Now lets take a closer look at the different bits of the interface here.Īt the bottom left you have a very important window: When debugging, you can interact with your code in a lot more detail. You can’t see it in the screenshot, but I am hovering my mouse over the e parameter, and it is popping up a tooltip showing its current value. Our code is currently paused executing on our breakpoint. Now if you head back to Webstorm, there will be a wealth of information available to you: This will immediately trigger the breakpoint, pausing your programs execution. ![]() With the breakpoint set, now flip back to Firefox and hit a key. ![]() You will see a red dot once your breakpoint is set, like so: Set a breakpoint by hitting CTRL+F8 or selecting Run->Toggle Line Breakpoint. Here we want to set a breakpoint, which will cause our code to stop when the breakpoint is hit. Go back over to Webstorm, open MyFifthApp.js, locate the line with onKeyDown: function, and select the line right below it. Now what we want to debug is debug the activity that occurs when the user presses a key. Voila, or app should load up in our browser: Select Run-> Debug ‘Your App’ or press Shift + F9 Navigate to your index.html or root HTML file, select Firefox from the browser dropdown and name it whatever you would like: Select it and file in the form like follows. On the left hand side, a new entry should appear. In the resulting dialog, click the + icon: In Webstorm, select Run->Edit Configurations… If you are doing web development, I assume you do already anyways. Next, to get the most out of Webstorm debugging, you should also have Firefox installed. Of course, any project will work, but that particular project has an interesting… quirk that will come in useful. I am going to use my most recent tutorial post on creating sprite sheets with Cocos2D if you want to download and follow along. If you are currently debugging using a combination of alerts, console writes and breakpoints in the browser, listen up!įirst off, you are going to need a project to debug. ![]() The process will change slightly ( different buttons/hotkeys ), but the instructions below basically apply to debugging in browser as well.Īt the same time it dawned on me… if you don’t come from a compiled code background, you probably don’t even realize what you have been missing! So, I have put this post together, it will hopefully make the developer experience better for at least a couple of you. Webstorm however integrates the process directly within the IDE. ![]() This is something that can make JavaScript development a WHOLE lot nicer.ĮDIT: I should make it clear at this point, virtually nothing in this guide is specific to WebStorm, you can debug using the Chrome Developer Tools or using Firebug in FireFox. But one of the biggest reasons is, it gives a rock solid debugging experience… very similar to native code. One of the big reasons is, its just a good solid text editor, with good project management and solid code completion, which is an area most tools fail at. In the past I mentioned and even recommended HTML5 developers give WebStorm a shot, this is the IDE I use personally when working in JavaScript, but I realized I never actually said why. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |