AIR with full screen - Print Dialog hidden

I had an annoying issue yesterday where I discovered that if I called Flash's print function (via PrintJob) in a full screen AIR app the print dialog wouldn't be shown - it would appear behind the main app window.

Took a bit of hunting around, but eventually I discovered that it was a simple case of setting:

alwaysInFront=false;

on the main AIR window (my main WindowedApplication).

Why it should have been set to true in the first place I have no idea.

Thought this might be useful for other people!

Flash, Air, Automated Builds...

I've been up to quite a lot at work over the last couple of months. It's not finished yet, but I'm quite proud of the progress, and wanted to document it somewhere.

Our build systems were already substantially automated. All our new Flash-based projects have been moved over to the Flex command-line compiler wrapped with Ant (we used to use MTASC in the same way). And the final 'publish' bit was also done with Ant (turn the produced .SWF into an .EXE, or an Air file, or a Mac .app). So everything was already command-line, on each developer's machine (the whole shebang in SVN to keep things in sync).

But we're ramping up for a new style of delivery. Previously, because we're working in quite a backwards market, we've been delivering on CD-ROM. We are still going to do that, but we're also going to be delivering the same content on-line in a number of different formats - AIR (our preferred option), .exe and .app (for those who aren't allowed to install AIR), and SCORM-compatible .zip at the very least. That's a pain to manage and publish.

Under the old regime, the developer working on the project would have had to clean-and-build-for-distribution 4 times (for the four different formats) to produce the final packaged products - in some cases 4 times per language. Which takes a helluva long time. And then would have to FTP or SCP the lot up to a server, and update a website with the new details etc... and some of those build cycles weren't that simple (moving to a Mac for the final Mac DMG, hand-building Windows icons for the .exe, hand-building Mac icons for the Mac .app, and so forth).

So I've been building a new build server to help us out in a number of ways. Here's what I've managed to get going over the last couple of months:

• Automated build of DMG files.


• Automated build of Windows .ICO and Mac .ICNS files from PNGs.


• Automated build on the server of any of our Ant-based projects, in a variety of formats. That's all the way from SVN code to a complete set of .air, .exe, .app, .dmg, plain .swf (for embedding online) and/or .zip files.


• Automated publication of the resulting products on to a website with various user 'channels' (so some users can get at some stuff that others can't).

All of which means that, to release a product to the public, a developer goes to a web interface and clicks 'build'. Everything gets built and uploaded to a central repository, the developer gets an email saying whether it's succeeded or not. Then the developer chooses which channels to publish it into, and bingo, people have instant access.

I am happy with this. There's a lot more work to do yet (on things like authenticated downloading, watermarking/serialnumbering downloads, and a whole new website to go alongside it all) but the structure is there.

Added to that we've also got out of it a couple of really useful tools for the production team, including a string/resources editor that any of our content authors can use - which lets them modify (in a protected way) the actual resource files the developers are using - and a module documentation system.

All of this achieved with a Mac Mini (for the Mac-specific DMG building and .ICNS building), a Dell server, PHP, Java, Ant, Cruise Control (which we've hijacked and are just using as a queuing system), Code Igniter, SVN, haXe and, of course, the Flex compiler.

Nice. :-)

Vector bug in FP10

Adobe's (nice) new Vector class has a bug in it.


var v:Vector.=new Vector.();

v.push("one");
v.push("two");
v.push("three");

// Tracing out vector here produces "one","two","three" as expected

// Stick a new value on the front
v.unshift("zero");

// Tracing out vector here produces "zero","one","two" -- eh? We've
lost the last element.

// This is the equivalent to unshift(), using splice instead...
v.splice(0,0,"minusOne");

// Tracing out vector here produces "minusOne","zero","one","two", as expected.


Annoying, but at least there's a workaround.

It's already on Jira, and has apparently been fixed - but I assume it's a Flash Player issue, so I'm guessing there'll be broken versions in the wild for quite some time to come...

https://bugs.adobe.com/jira/browse/ASC-3620

Memo to Self: Soundflower

Adds an extra device to the Mac's list of sound devices so that you can record the current output of your soundcard:

http://code.google.com/p/soundflower/

No more Fx!

Excellent news from Adobe.

Common sense prevails. :-)

Tweensy

A new AS3 tweening engine: Tweensy.

Alleged to be the fastest yet, with a whole bunch of interesting features.

Maybe someday I'll get a chance to look at it!

PNG Artefacts with wmode=transparent

A friend's SWF had really odd pixel artefacts being drawn on the background of an animation - but only in Firefox with wmode=transparent.

This is a problem that I hadn't seen before - I've blogged about the problem and solution on the Awen code site, here.