Archive for fdt

Creating AIR applications with FDT

Posted in Actionscript, AIR, Bugs & Solutions, Development with tags , , on September 25, 2009 by andkrup

How do you create AIR applications in FDT?

By googling ‘fdt air’, you get these 2 fine links:

http://fdt.powerflasher.com/blog/?p=10

and

http://www.martijndevisser.com/blog/2008/building-air-with-fdt/

These posts are very nice introductions, but there is something you might want to check out.

Flex SDK version

If you decide to use the Flex SDK with the included AIR, you should use the descriptor xml file that is included with the SDK version you are using.

I got some “descriptor version does not match runtime version“- and subsequently “application filename must have a non-empty value“- errors, because the descriptor xml file format was changed.

Using the sample descriptor file included with the SDK, you will be certain that the format fits the adl executable.

Icon problems

I also encountered some difficulties with packaging icons. I got the error “error 303: Icon icons/AIRApp_32.png is missing from package”, which, as it turned out, comes out when there is a mismatch between where the icon files will be placed in the package, and the icon arguments in the descriptor file. It would be nice to look into this further.

One solution is to comment out any icon tags in the descriptor file, package and then unzip the resulting *.air file (as it really is only a zip file) in order to find the location of the icons. Then put that location into the icon tags and uncomment them in the descriptor file.

Advertisements

Creating a swc library with selected packages in FDT

Posted in Actionscript, Development with tags , , , on May 9, 2009 by andkrup

Sometimes you need to expose only part of your code library in a swc code library file. Maybe you work with propriety code, but also have the need to expose your framework to external developers, so you create some pretty interfaces that externals can use without exposing company code.

One way of distributing these interfaces can be to create a swc library file that only holds your public interfaces.

The compc compiler gives you some options to specify what classes, interfaces, namespaces or packages to include, but when using the Run-configurations that comes with FDT, FDT automatically adds the whole shebang. This is ok for a swc file with no secrets hidden (no mention to decompilers)

As I remember it, the Flex-plugin/editor gives you a nice ui to select what packages to include in your swc file, but FDT is a bit more old-skool.

In this example i use the -include-sources compiler option, but the compc compiler also has the -include-classes option which gives you fine-grained control over what classes and interfaces are exposed in your public swc library file.

In FDT this is one way to do it:

    1. Create a new “FDT AS3 Library” in “Run Configurations…”
    2. Select the “Compiler Arguments” panel and uncheck the checkboxes “Auto add project classpath to arguments” and “Auto add project SWCs to Arguments”. Auto add project classpath…” will insert classpaths to all your packages, which is not the intention, and the project swcs are only needed if your code relies on the definitions found inside the swcs
    3. Insert a -source-path option. Working on a PC for a change, I found that I had to use the full path, no quotation marks and with abbreviated folder names. This means that the path variable for the -source-path option looked like this:
      -source-path=c:/docume~1/<userna~1>/mydocu~1/eclips~1/<projna~1>/src
      

Also remember to use the equals sign

    1. Insert a -include-sources option for every package you want to expose using the same fill path syntax rules. This means that if I want to include my com.andkrup.externalmodules package, I need to add this:
      -include-sources=c:/docume~1/<userna~1>/mydocu~1/eclips~1/<projna~1>/src/com/andkrup/easygame/extern~1/
      
    2. Apply and run.

The <userna~1> indicates that you should exchange it with the abbrevciated name of your user-folder. The same goes for the <projna~1> which indicates that you should exchange it with the abbrevciated name of your project-folder.

FDT will add the output option based on your Output-setting in the “Main” panel.

On the PC I found the compc compiler to act extremely picky about the syntax, using eclipse/FDT. It was very easy to get compc to compile in the commandline, but it seems that you have to be careful about whitespace and line-breaks/returns when you add custom arguments in the “Compiler Arguments” panel in eclipse/FDT.

I was banging my head on the keys for a long time, trying to get compc to accept quoted paths as this:

“C:\Documents and Settings\…”

It seems that when you specify arguments in the “Compiler Arguments” panel, you have to use dos-abbreviated folder names in the path variable which also must not be quoted.

When I get back from the weekend, I’ll have to check how it works on the Mac.

You could also create an ant build file to do the same job, but this post was primarily about how to use the FDT AS3 Library Run configuration.

edit: Instead of using the full absolute path, FDT declares a project-path variable which makes the launch settings more portable. Please read the comments for more information

FDT workflows

Posted in Actionscript, Development, Instructional with tags , , on April 1, 2009 by andkrup

A nice description of workflows in FDT

http://hibbins.wordpress.com/2008/12/12/one-way-or-another/

Whitespace

Posted in Development, Uncategorized with tags , , , , , on November 21, 2008 by andkrup

Earlier today I stumbled across one of the basics in general computing.

As I tried to create some small actionscript library components in FDT, the compc did not output the expected swc in the location specified. As of now FDT can automatically create an output folder, call it bin, deploy or whatever, when you create a new Flash Project, and creating a FDT-Library Run configuration will net you a nicely compressed swc file in said output location.

Instead I got nothing, and trying to checkout a previously good project from svn and building had the same effect.

Scanning the log, I found that instead of feeding the usual output location (/User/<username>/workspace/project/bin/library.swc) to the compc, FDT was sending in a path that looked something like /usr/private/fdtTmp/fdtTmp7578, and I got to spend some time grumbling why that happened. Google had no real help to offer.

It turned out that mac doesn’t really allow the eclipse/FDT to have any spaces in any path when executing compc, be it either in the workspace location or project location.

A basic rookie error, and I guess the years on Windows has had a placating effect.

Should be nice with a slap in the face from the *nix based platforms.