Using FDT's Debugger

From FDT Documentation

Jump to: navigation, search
FDT's Debugger In Action

Powerflasher first introduced a debugger with version 3 of FDT. Since then, many improvements have been made. Now that version 4 also includes a profiler, Flash developers are now more armed than ever to take on buggy applications.


Source Files

Download soruce files.png

Getting Started

Check For Debug Version of Flash Player

Before venturing into using FDT's debugger, you'll need to make sure you have the debug version of the Flash Player installed. There are two easy ways to determine if you're using the debug version:

  1. Go to Adobe's detection website Img preview.png.
  2. Confirm that your stand alone Flash Player (located on your hard drive) is the debug player Img preview.png.

If you have the debug version of Flash Player then you're ready to get started, if not you'll need to install it.

Install Debug Version of Flash Player

If you don't have the debug version of Flash Player, getting it is easy. Simply go to Adobe's Flash Player Support Center and choose the appropriate installation for your operating system Img preview.png.


Sometimes an OS update, a browser particularity or multiple installations of the Flash Player will still cause problems with debugging. If you're still having trouble getting FDT to connect to the Flash Debugger, check out these resources for uninstalling Flash Player, do you can then reinstall the debug version of Flash Player:

Import Trace Template

After you've Downloaded and Imported the sample project for this lesson, you'll find a template file that will adjust FDT's default Quicktrace template as well as load in a new trace() method Img preview.png. It's not necessary for this lesson to have these templates installed, but they can be helpful. If your're not sure how to import code templates (snippets), check out Creating Code Templates.

Sample Project's Source Code

Once you have have the project imported, or have you're own setup, let's look at the example code :


<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="" 
		import flash.display.Sprite;
		private var null_object : Sprite = null;
		private var xml_data : Data = new Data();
		private function trace_complete(event : FlexEvent) : void {
     		trace('My App Is Ready');
		private function trace_event(event : MouseEvent) : void {
     		trace(this, ' @ trace_click', ' :: event = ', (event));
		private function trace_data(event : MouseEvent) : void {
			trace(this, ' @ trace_click', ' :: event = ', (;
		private function trigger_runtime_error(event : MouseEvent) : void {
			null_object.height = 10;
		private function trigger_breakpoint_nested(event : MouseEvent) : void {
		private function step_through_code(event : MouseEvent) : void {
	<s:Group verticalCenter="0" horizontalCenter="0">
			<s:VerticalLayout horizontalAlign="center">
	<s:Button id="trace_btn" label="Trace Event" 
	<s:Button id="trace_data_btn" label="Trace Data" 
	<s:Button id="error_btn" label="Trigger Run Time Error" 
	<s:Button id="breakpoint_btn_2" label="Trigger Breakpoint In Nested Object"
	<s:Button id="breakpoint_btn" label="Step Through Code"

package demo.debug{
	public class Data {
		private var _data : XML = <books>
    <title>ActionScript Cookbook</title>
      <author name="Joey Lott" />
    <title>Flash Cookbook</title>
      <author name="Joey Lott" />
      <author name="Jeffrey Bardzell" />
    <title>Flash Remoting: The Definitive Guide</title>
      <author name="Tom Muck" />
    <title>ActionScript for Flash MX: The Definitive Guide</title>
      <author name="Colin Moock" />
		private var _my_var : int;
		public var array_of_data : Array = [1, null, '1', "one"];
		public function trigger_breakpoint() : void {
			trace(this, ' @ trigger_breakpoint', ' :: _data = ' , (_data));
		public function run_counter() : void {
		private function do_count() : void {
			_my_var = 0;
			trace(this, ' @ do_count', ' :: _my_var = ', (_my_var));
		public function get data() : XML {
			return _data;

This project has two classes, Main.mxml and Img preview.png. While this is a Flex project, the same debugging techniques can be used in an ActionScript only project.

Launching An Application in Debug Mode

Compiling and connecting to the debugger is simple. There two quickest ways are:

  1. Just right click on your Main class either in the Flash Explorer or within the Editor and choose Debug As>FDT SWF Application Img preview.png.
  2. From the Debug Menu choose a launch configuration to run in Debug mode Img preview.png.

If you're following along with the example files, once you launch your .SWF, you'll see the External SWF Viewer appear with a few buttons on the stage Img preview.png. We'll get to what the buttons do in a little bit. For now, move the External SWF Viewer to the side and take note of the console on the bottom of the screen Img preview.png.

*If the console view isn't visible go to: Window>Show View>Console to reveal it Img preview.png.

If the console reads:

Using Flex SDK 4 Debugger Adapter.
[Info] Connection to player established.
[Loading] Loaded: ::Users:OSX:_dev:fdt:Debugging_Start:bin:Main.swf

Then FDT has successfully began the debug session. If not, recheck that you have the debug version of Flash Player installed and that all other Standard versions of Flash Player have been uninstalled from your OS.

Using Trace() to Output Messages

With the example project compiled and running in debug mode, we can already see the most popular and simplest technique for debugging - the trace() method. The trace method is a top level function that all Flash applications have access to. It allows developers to output text messages to whoever is listening. In this example the console view is listening for these messages.

Trace a String

Already the console is picking up on a message via trace:

My App Is Ready

This is a message that is being sent from a trace() statement within FDT. In our example it's coming from the trace_complete method:

private function trace_complete(event : FlexEvent) : void {
     trace('My App Is Ready');}

This type of tracing is the simplest way of sending messages.

Trace An Object & FDT Quicktrace

If you use FDT's quicktrace keystroke (move cursor over an object and press Cmd+0) or the quicktrace methods supplied in the tutorial snippet , you will notice that within the trace method there is an Object being referenced that is not a string :

private function trace_event(event : MouseEvent) : void {
     trace(this, ' @ trace_click', ' :: event = ', (event));}

In this example the event object is being sent out to the console. To see the output, click on the Trace Event button within our application Img preview.png. When this happens, another message will be sent to the console Img preview.png. This time the message is different. When this happens the console will output additional information about that object. In the case of event, we get this type of output:

Main0  @ trace_click  :: event =  [MouseEvent type="click" bubbles=true 
cancelable=false eventPhase=2 localX=81 localY=18 stageX=314 
stageY=154 relatedObject=null ctrlKey=false altKey=false 
shiftKey=false buttonDown=false delta=0]

Other times we will see a Type output or a fully qualified name of the object being traced. In the case of an XML object, we'll have the entire XML object spit back at us. WIth the example project, click on the Trace Data button and the console will show us an XML output Img preview.png.

The Debug Perspective

While the trace is very, very handy - it's really just a taste of what the debugger can do. There are numerous ways to switch to the debug perspective. Learn more about perspectives and getting to to FDT's Debug perspectives with the Navigating Your Code and FDT's Workspace tutorial.

Switch To Debug Perspective

For this example, we're going to have FDT automatically switch to the Debug perspective for us when it encounters a runtime error. Initiate an error by clicking on the Trigger Run Time Error button with our .SWF Img preview.png. Immediately an error will occur and FDT will ask if you want to switch to the Debug Perspective Img preview.png. Click Yes and FDT will then switch to the Debug Perspective.

013 016.png

Views And Panels

Views and panels can be moved around at will - just like any other perspective. If you ever need to how a view that is hidden, simply go to Window>Show View Img preview.png.

For this tutorial we'll just focus on 3 views:

  • Debug
  • Breakpoints
  • Variables


The Debug view is perhaps the most important. It acts like the 'control center' for debugging applications Img preview.png. It displays two important things:

  1. The current thread.
  2. The Call Stack of the current thread that contains Stack Frames.

Ok, so the current thread information isn't terribly relevant because Flash is single threaded - but inside that thread we have the Call Stack

The Call Stack is where you find out where the error occurred and how you got there Img preview.png. The stack frames are displayed in order from (going from to bottom) most recent frame to first frame. If you click on a stack frame, the Variables and Editor view will update with information about the Object and variables are that are present in the frame: Img preview.png & Img preview.png.

This view has a few controls as well:

Resume.png The Resume will resume the execution of the .SWF (if it was stopped via a breakpoint), this will continue until it hits the next breakpoint.

Terminate.png Terminate will stop the debugging session. The button here in the Debug panel/view is the same as the Terminate button within the Console view.

Step controls.png The Step Controls allow you to walk through the program as it executes.

  • Step Into Executes the current line. If the line is a call to a method or constructor, and there is source available for the called code, the program counter moves to the declaration of the method or constructor. Otherwise, the program counter moves to the next line in the file.
  • Step Over Executes the current line and moves the program counter to the next line of the file. If the executed line is a call to a method or constructor, the code in the method or constructor is also executed.
  • Step out of/Return Executes the rest of the code in the current method or constructor and moves the program counter to the line after the caller of the method or constructor. This command is useful if you have stepped into a method that you do not need to analyze.

* Step Into and Step Over can be confusing. The main difference is that when using Step Over, the debugger will just call the method and move to the next line. If you were using Step Into, the debugger will go inside that method and walk through all the code there.


This view will show you any Breakpoints that have been set in your code. This application only has one break point set Img preview.png.

When setting breakpoints it's important not to put multiple statements on a single line because you can't step over or set breakpoints on more than one statement on the same line. So:

		private function do_count() : void {
			_my_var = 0;
			_my_var++;_my_var++;			_my_var++;
			trace(this, ' @ do_count', ' :: _my_var = ', (_my_var));

In the highlighted line above, the debugger will not have any way to pause between the two statements.


Depending on what Object you have selected in the stack trace, FDT will analyze the objects within the current scope. It will give you the instance name as well as the value associated with it. You can even change the values of variables while the code is executing.This is a very powerful view

013 021.png

Analyzing Your Application

We just got done introducing the Debugger and showed what happens when Flash encounters a runtime error. Now lets take some time to use the debugger to analyze our application.

Setting A Breakpoint

Return back to the Flash FDT Perspective and open up the class Img preview.png. Go to line 33 and double click within the margin to set a breakpoint Img preview.png. What a breakpoint will do is stop right before it executes the line where the break point is set. Then once again launch your application in debug mode Img preview.png.

When the application runs, click on the Trigger Breakpoint in Nested Object button Img preview.png. When FDT asks you to switch to the Debug perspective, do so.

013 027.png

Viewing The Call Stack & Stack Frames

Let's take another look at the Stack Frames - we can now see how we got here.

013 028.png

Start stepping back through each frame and notice how the Editor and Variables view are being updated Img preview.png & Img preview.png. We're in effect stepping backwards through the program.

Now let's go back to the topmost Stack Frame and begin to expand the Objects within the Variables view Img preview.png. Here we can see the _data reference and the data it's pointing to - in this case it's XML data. The output, as a toString method, is also visible below the object navigator.

Step Execution

Although breakpoints are very handy in that they allow us to pause our application and take a look, breakpoints are even more useful when used in combination with the Step Execution controls.

If your still in a debugging session, terminate it now. Now add a breakpoint to line 36 of the example project Img preview.png and debug it again. This time, click on the Step Through Code button Img preview.png.

Once back in the Debug Perspective, click on Step Return Img preview.png and you'll see FDT automatically execute the rest of the method (check out the console to see additional trace statements added) and return to the Button component - the place where the step_through_code method was called [1].

Instead of exiting out of the debug session, let's just resume it by clicking on the Resume button Img preview.png. The debugger will un-pause the application, but still stay connected. Once again, let's trigger another breakpoint by clicking, again, clicking on the Step Through Code button Img preview.png. This time, click on the Step Over button Img preview.png and notice how FDT will execute the next line of code, the method run_counter, and then pause before it runs the next line. We can tell that the run_counter method was executed because an additional trace was added to the Console Img preview.png.

Now let's give Step Into a try. Without un-pausing or terminating the session, click on the Step Into button Img preview.png. The debugger will now navigate to the definition of the run_counter method - which is located in the Data class. Continue pressing Step Over until you hit line 41 , or the line where the do_count method is declared. Once here go to your Variables view and let's take a closer look at what we have. Start expanding the variables of this object and take note how you can inspect each variable and it's value.

013 046.png

The first line of code is this:

_my_var = 0;

In the Variables view we can see that the current value of _my_var is 4. Once more, press Step Into to have FDT move to that first line of code, but notice how the assignment hasn't taken place - _my_var still has the value 4. Now, keep an eye on _my_var and continue to Step Into. You'll notice that _my_var is reset to 0 and then incremented by one. As you're stepping though this, notice how when the debugger hits this line:

		private function do_count() : void {
			_my_var = 0;
			_my_var++;_my_var++;			_my_var++;
			trace(this, ' @ do_count', ' :: _my_var = ', (_my_var));
		} executes both statements. This is because the debugger will not step through statements, rather it steps through lines of code.

Changing Variables

Before executing the trace statement, lets change the _my_var to something else... how about 1,000,000 Img preview.png! After changing the value of _my_var, press Step Into again and watch how the trace statement then outputs 1000000 to the console.

Using Step Return To Backtrack The Call Stack

Now that we've tunnelled deep into our application, let's go backwards up the Call Stack. When you begin pressing Step Return you will begin going backwards through the each stack frame until eventually you return to the top most calling method, which in our case, was that Button. Keep an eye on the call stack in the Debug view to get a better understanding of where you are.


Q: Why doesn't FDT either switch perspectives or ask me to switch perspectives?

A: Check out the FAQ: FAQ#When_I_Debug_or_Profile_My_Application.2C_The_Perspective_Doesn.27t_Change

Wrap Up

There's a lot that can be achieved using the debugger, take the time to play with it and see just how much you can do using it.

Get FDT5