FlashPlayer 10 and loading AVM1 content

November 20th, 2008 • 1 comment AIR, ActionScript, Flash
Tags: AIR, AS3, Flash

I’m using some swf assets directly exported from Illustrator CS3. You can export Flash 9 swfs, but as you can’t add any code there you will always get AVM1 content (AS2.0). So it’s basically just an information in the header and maybe Adobe will put an option in the export-settings to actually publish AVM2 swfs. I haven’t tried CS4 so far, maybe it’s in there already?!
Anyway, loading this swfs and moving it to another part of the displayList didn’t cause any problems using FlashPlayer 9. In FlashPlayer 10 I get the runtime error 2180:

Error #2180: It is illegal to move AVM1 content (AS1 or AS2) to a different part of the displayList when it has been loaded into AVM2 (AS3) content.

There are a few options to avoid this error:

• Don’t load AVM1 content respectively create the assets in Flash to get AVM2 swfs
• Don’t move the assets in a different part of the displayList
• Change the SWF header on-the-fly

The last solution seemed to be perfect and remembering the AVM2Loader class someone created in the upcoming AS3 times it was the easiest solution without changing the workflow. Even if the author Fladdict removed the class, you can still find it on the internet at Troy Gardners blog.

Update 20.11.2008

To use this workaround in an AIR application you have to set allowLoadBytesCodeExecution = true in your LoaderContext otherwise you aren’t allowed to load the bytes of the swf.

...
var loader:Loader = new AVM2Loader();
var loaderContext:LoaderContext = new LoaderContext();
loaderContext.allowLoadBytesCodeExecution = true;
loader.load("file.swf", loaderContext);
...

Compiling AIR or what is the right SDK

November 17th, 2008 • AIR
Tags: AIR

This is no tutorial about creating ant build files and so on. you can find a good one with a sample project at the FDT blog. It’s for AIR 1.0 but you just have to change the descriptor xml to the new format and it should work.

This post is all about using the right SDK. With the release of AIR 1.5 some of you might switch and run into the same problems I did when I set up my first AIR project. Compiling for AIR is a little bit more strict and bound to the SDK than compiling for FlashPlayer. If you want to target for instance FlashPlayer 9 you could use Flex SDK 3.0, 3.2 or even a beta release of Gumbo (4.0), as long as you don’t use any of the classes or functions that are related with FlashPlayer 10 (e.g. the Vector class).
Compiling for AIR is a little bit different. The SDK is more or less bound to the version you want to target, so you have to use the right SDK in combination with the right definition in the application descriptor file.

<application xmlns="http://ns.adobe.com/air/application/1.1">
...
</application>

As you can see this descriptor is for AIR 1.1. If you try to compile with the SDK 3.2 which targets AIR 1.5 you will get a compile error (“error while loading initial content”).

Just keep that in mind and use the right SDK:

• AIR 1.0 – Flex SDK 3.0
• AIR 1.1 – Flex SDK 3.1
• AIR 1.5 – Flex SDK 3.2

You can find a list of milestone releases, stable and nigthly builds at the Adobe Open Source site.

AIR 1.1 – hiding the mouse cursor

November 16th, 2008 • 7 comments AIR, ActionScript
Tags: AIR 1.1, AS3

Adobe AIR is out quite a while now and you might think that at least all the functions being in the FlashPlayer for years are implemented correctly. Obviously this is only wishful thinking because I wasn’t able to hide my mouse cursor through Mouse.hide() even though the documentation says that it’s possible. I couldn’t reproduce the same thing on Windows so I guess it’s only a problem on OSX and maybe Linux (but who really cares about linux?). After investigating quite a while I found out that the cursor disappears after moving it out of the window and back in or switch to another application and back but you can’t tell the user "please move your cursor out of the window and back in" or at least it’s not very nice and user-friendly. I tried every possible setting for the native window and finally found a workaround … wohoo.

Try the following in your document class and your cursor is gone, hopefully!

stage.nativeWindow.activate();
stage.nativeWindow.orderToBack();
stage.nativeWindow.orderToFront();
Mouse.hide();

Basically this sends the window behind all the other windows and brings it to the front again immediately. You won’t see the change or any flickering. After that you can hide your cursor.

Update 17.11.2008

Adobe just released AIR 1.5 but seems like this problem is still there. The workaround is still working so keep on rockin’ or should I say hiding

AIR 1.1 – Maximized Window at Startup

November 16th, 2008 • AIR, ActionScript
Tags: AIR 1.1, AS3

There are a lot of settings for the initial window in the application descriptor file but none for getting a maximized window at startup. To achieve that you have to call stage.nativeWindow.maximize() in your Document Class. This works fine but you’ll actually see the small window being maximized and this isn’t very cool. To avoid this you can set visible = false for the initial window in the descriptor file and show the window after maximizing it but take into account that the maximize() method is asynchronous and therefore setting stage.nativeWindow.visible = true right after the call won’t change anything. Use the NativeWindowBoundsEvent.RESIZE event to determine when your window size has changed.

...
public function Main()
{
	stage.nativeWindow.addEventListener(NativeWindowBoundsEvent.RESIZE, resize);
	stage.nativeWindow.maximize();				
}
private function resize(event : NativeWindowBoundsEvent) : void
{
	// show window + set keyboard and mouse focus
	stage.nativeWindow.activate();
}
...

Apparently this works on OSX but not on Windows. There the window has to be visible in order to maximize it. I didn’t do many tests so prove me wrong if you have other experiences.

FileReference upload II

November 13th, 2008 • 1 comment ActionScript, Flash
Tags: AS3, FileReference, Flash

A few weeks ago I posted about some issues with the FileReference Events in combination with Anti-Virus Tools. Apparently there is another problem even without using such tools. If your upload bandwidth is very low, lets say less than 100 kbit/s or even worse if you are using a good old modem (56kbit/s) to connect to the internet, you might get into trouble handling the IOErrorEvent.IO_ERROR Event. You will get #2038 FIleIOErrors during an upload process on slow connections even though your upload is fine and the file is hitting the server correctly. Actually there is a correlation between the connection speed an the file size.
The bigger the files (>500KB) and the slower the connection the more often you’ll get an IOError.

I think even in AS3 times it’s sometimes better to reclaim good old AS1/AS2 times where error handling didn’t play a major role and just don’t listen to every error event that could occur.