I have seen a few workarounds, but none as simple as a tip I overheard on Twitter from Ted Patrick. So here it is, either read on, or watch a quick two minute screen-cast I put together.

1. Create a new Flex Project in Flash Builder.

2. In the New Flex Project Wizard, give your project a name

3. Choose Desktop (runs in Adobe AIR)

4. Select “Next >” in the wizard

5. Still in the Wizard click “Next >” again to bypass the Ouptut folder ( you can change it if you feel so inclined )

6. Still in the Wizard change the file extension of your Main application file from .mxml to .as

7. Select Finish

When you compile, and run the application in ADL, you won’t actually see the native window. Here is where the tip from Ted Patrick comes in. In your application-descriptor.xml file, change the visible tag to true. Compile and run. You should have a nice native window showing up. You can set the initial width, height, backgroundColor, and frameRate using the [SWF] annotation / meta-tag.

Optionally, if you would rather wait to have the native window be visible, you can do so using ActionScript by setting the visible property of the nativeWindow instance of the stage like so:

stage.nativeWindow.visible = true

I’m excited to be going to ATL. The last Adobe event I attended there was the “On Air Bus Tour” a few years back. My impression of the Flash / Flex community there has always been a good one, and based on some recent Twitter chatter it seems that there are over 200 tickets sold. Should be a great event. If you are in the area, or want to get away for a few days it looks like there are still tickets available.

See you there.

Jason

Lately I’ve just really dreaded the Flash editor. I realize that it could come off as spoiled, but I really dislike typing out the usual skeleton code to get a class file started. Tonight I decided that I’d had enough, so while the students were working on projects, I decided to update my extension. I call it the DocBuilder. It asks you for the package, class name, and what class you would like to extend. It then asks you to save the file in the appropriate directory to match the package. Viola!!!! Stub code generated.

Here is a screen shot of the outputted class skeleton:

Feel free to download the extension from here.

Update: I found and fixed a small issue where the help button gave an error. The linked file above is the latest version and seems to be working well.

jason

Norm Soule has released v1.0 of his new PixelBlitz Engine. It is a system for utilizing BitmapData to represent your MovieClips and Sprites. There are several built in features (layers, pixel level collision detection, etc) but the most impressive reason for using it is the speed. There are several demos, full documentation, and commented examples. Definitely something to look at for highly interactive content, or game development. As I get into it a bit deeper I will put together a more detailed review and an example or two. At first glance this seems REALLY impressive.

jason

Jason

In order for Flex to recognize your Custom Event you need to include the event meta data in your AS Class file. For example, in an AS setting your class could fire off an event like so:

private function updateHandler(e:MouseEvent):void
{
    var evt:MyEvent = new MyEvent(MyEvent.VOLUME);
    evt.volume =//some volume value;
    this.dispatchEvent(evt);
}

In an all ActionScript setting this works fine. However when you compile this UIMovieClip into a swc file and use it in a Flex Project, Flex has no way to recognize the MyEvent.VOLUME. In the Flex Editor it won’t appear as a code hint. If you manually force it into the MXML, you’ll get an error. In order to allow Flex to know of the event you will need to include some Event meta data at the top of your ActionScript Class. For example:

[Event (name="volume", type="com.knomedia.events.MyEvent")]
public class VolumeControl extends UIMovieClip
{
    //Class members here
}

The meta data needs the ‘name’ of the Event. This is the string literal that the event constant holds. In this case MyEvent.VOLUME holds the value “volume”. The type attribute is the fully qualified name of your Custom Event Class. The placement of the meta data is important, it needs to be on the line above your class declaration. Once you have that in place you can compile your swc.

My only beef with the technique is that you need to use the actual string literal. I understand the need (for ease of use in MXML), but I am more comfortable using class constants of the Event Class… Anyway.

In MXML you can now set the volume attribute to listen for the event to fire:

<swc:VolumeControl id="vol" volume="{volumeHandler(event);}" />

The switch from all ActionScript to MXML is pretty painless. Occasionally a small issue like this will make you feel stupid, but overall it isn’t a big jump.

Jason