FDT, Ant, and Debugging

October 6th, 2008

We’ve started switching over to FDT Enterprise ActionScript editor for our larger projects. To streamline workflow we’ve started to use Ant for compiling swfs out of FDT. One of the much-appreciated new features in the latest FDT version is the ability to run the debugger against an Ant compile (as opposed to the more common Run/Debug configurations).

What is Ant, and how can it help me?

I found this to be a good primer on using Ant with FDT. It maps out examples of how to author an Ant build file. Note that this post doesn’t make use of the built-in Ant tasks, but it illustrates Ant’s flexibility.

FDT’s Built-in Ant Tasks

FDT has several built-in Ant tasks, documented in the FDT User Guide. On a Mac this is found at Help > Dynamic Help. Click on “All Topics” on the bottom of the panel and you can select the FDT User Guide. Ant Tasks are covered in section 2.4.7, “Using Ant”. Note that the top-level page is empty, so hit “Next” when you’re on that page to go to section 2.4.7.1.

To use these Ant tasks you have to be using the Flex SDK as your core library, not CS3. To change an existing project’s core library, pull up the project’s Properties panel and go to FDT Build Path. Make sure that the Known Libraries drop down and Library Settings are set to the same SDK. I’m not sure why there’s two places where you can set this.

  1. Simple Compile
    1
    2
    3
    4
    5
    
    <project default="default">
    	<target name="compileShell">
    		<fdt.launch.application projectname="eltricolor" mainclass="${classesdir}/com/eltricolor/Shell.as" debug="true" compilerarguments="-default-size 1000 603 -default-frame-rate 31 -default-background-color 0x000000" target="${deploydir}/shell.swf" startswf="false"/>
    	</target>
    </project>

    The compilerarguments attribute can be used to specify additional mxmlc compiler arguments

    A project can have multiple targets, and the default attribute in the project tag specifies which target is the default. This is handy when working on a section of a large site, where you can use the hotkeys to trigger the default Ant build instead of having to click on it.

  2. Compile with Debugging
    1
    2
    3
    4
    
    <target name="launch">
    	<fdt.startDebugger projectname="eltricolor" savelocation="launcher"/>
    	<fdt.extSWFViewer.startSWF file="${deploydir}/shell.swf" width="1000" height="600" flashvars="link=ccc51ce410c124a10e0db5e4b97fc2af3913" />
    </target>

    Here we have two FDT Ant tasks - the <fdt.startDebugger /> task cues up the debugger, and the <fdt.extSWFViewer.startSWF /> task actually opens the specified swf.

  3. Compile a SWF/SWC using the Flash IDE
    1
    2
    3
    
    <target name="compileCoreAssetsSWC">
    	<fdt.flashCompile file="${basedir}/dev/fla/CoreAssets.fla" failonerror="false"/>
    </target>

    This task will compile the specified FLA file(s). I found it to be most useful if I needed to pre-compile a SWC file for use by class that I’m compiling.

  4. Multiple Compiles

    Each compile target can be made part of a larger chain of compiles. I usually have a “compileAll” target that looks like this:

    1
    
    	<target name="compileAll" depends="compileMain, compileMenu, compileSound" />

    Another common task that I set up is one to launch the project after compiling everything:

    1
    
    	<target name="compileAllAndLaunch" depends="compileAll, launch" />

Debugging

This is a good rundown on debugging with FDT: FDT Debugging Tutorial.

The integrated debugger appears to be a “feature” of the Enterprise Edition, which is unfortunate since it’s such a basic feature in my opinion. It’s pretty much the same as the FlexBuilder debugger - you set breakpoints and can step in/over/through code execution. What’s sorely missing is watch statements, so you can’t select a few variables to watch during the execution phase. You can still drill down into the variable tree during breakpoints, but it’s still mildly annoying to have to do this.

Assorted FDT Weirdness

Naming matters: FDT apparently looks up class definitions in reverse-alphabetical folder order, so it’s a good idea to put SWC files in a folder that’s alphabetically at the top (like assets). Otherwise FDT will pull the class definition from the SWC and not the “raw” class file. Why is this bad? The definition pulled from the SWC will only have the class signature and not the full class, with XXXs where params are expected.

Leave a Reply