Archive | April, 2019

Marching Ants selection rectangle

16 Nov10

Five years ago, Mario Klingemann posted a quite clever way of creating a Marching Ants selection marquee like the ones you find in imaging applications like Photoshop or Fireworks. Today I needed a similar effect that also worked for non-rectangular selections, so I updated Mario’s class to AS3. I’m quite sure Mario don’t mind that I post it here for others to find.

You’ll find an extended usage example at the top of the class.
Download here and then place it in the correct folder (i.e. YourProjectFolder/com/quasimondo/tools/

This content requires Flash Player 9 (or a more recent version). You need to upgrade your Flash Player

Updated: of course - Mario had already updated and posted this to his Google Code repository…. Too bad I didn’t think of checking for that…

BigImageLoader now supporting even bigger images

23 Aug10

Just a quick post to tell that my AS3 class for handling upload of big images have been updated to catch errors where a user will upload images larger than 20Mpix.

PS: it’s been silent here lately, but I’m quite active on Twitter :)


02 Jun10

Just a quick update to tell that I’ve been working with UG manager Thomas Nesse to put on a FlashCamp in Norway. It’s called gotoAndSki(); and will be hosted at Juvasshytta by the foot on Northern Europe’s largest mountain - Galdhøpiggen! There’s a summer ski resort there so we’ll go snowboarding during day and have the FlashCamp in the evenings :-D

I’m really looking forward to this event and it’s all in English so feel free to join us! One of the things I can’t wait to try is getting my internals rearranged using Fernando’s Airboards!


AVM2 bug when rolling over movieclips

22 Apr10

When making examples for a recent workshop, I stumbled over a bug in the Actionscript Virtual Machine used for Flash Player 9 and higher (AVM2). If you are using a movieclip inside a button, the hit area won’t work as it should. When moving the mouse across the button, it will constantly blink giving a very flimsy impression. You can test this in the example below.

This content requires Flash Player 9 (or a more recent version). You need to upgrade your Flash Player

Here’s source files that show the bug and the fix FLA - SWF -

Switching the movieclip to graphic fixes the issue, but why won’t this work? It’s always worked well before, so this must be a bug in AVM2? Another thing is that if you hover this button for a few seconds, the Flash IDE crashes instantly…

If you’re unable to repoduce the bug - feel free to check this video that shows it and please post a comment telling what Flash Player version/browser you are using. I’ve been able to reproduce the bug on all OSX browsers + IE8 on Win7.

Submitted this as a bug in the bugbase

Away3D training - across the world

22 Apr10

My friend Rob Bateman is setting up Away3D workshops all over the world these days - Sao Paulo, Buenos Aries, Sydney and London. If you’ve been thinking about getting into 3D in Flash, I highly recommending attending one of these workshops. They’ll teach you all you need to get started.

Rob is also the lead developer of Away3D and has done lots of workshops on it so he is certainly the one to learn from. Read more on the Away3D Blog.


Handling user upload of big images

28 Jan10

Working a lot these days so few posts, but I made a class for a project that some may find handy. When you let users upload pictures using the Flash Player 10 local FileReference feature, you can get all kinds of image sizes (and content!). Most modern cameras have quite a few megapixels and Flash Player 10 can easily choke on large pictures.

FP10 has problems with images that have width or height larger than 8191 pixels. This is still much better than the 2880x2880 pixels we had to work with in FP9 so that alone is a great reason to insist on FP10 for this kind of applications. There is also another limitation mentioned in the official documentation that says “the total number of pixels cannot exceed 16,777,215 pixels”. I’ve found that this isn’t a problem for this implementation, so users can easily upload 8000x8000 pixel images without causing problems. The class will take the uploaded image and scale it to whatever max size you want. If the uploaded image is smaller than the max, it’ll leave the image unchanged.

Using the class is straightforward. Just make an instance and pass in what you want returned as the maximum width/height:

var bigImageHandler:BigImagehandler;
bigImageHandler = new BigImagehandler( 1500 );

and then add listeners to respond to what the user does:

bigImageHandler.addEventListener(Event.CANCEL, userFail);
bigImageHandler.addEventListener(Event.COMPLETE, userSuccess);
bigImageHandler.addEventListener(Event.CLOSE, userCancel);

Click here for example (Source code)

The project I did this for is also quite cool and I’ll give a small presentation of it on the next FUGN meetup. It’s a small app that’ll allow you to make yourself old. Just upload an image (or use a WebCam), position facial features and you can turn on/off wrinkles, hair and more. Feel free to give it a spin! Click the image my old self to get started making your own. (Note: the app is in Norwegian, but I’m sure you’ll figure it out by just clicking around)


Extra return in Textfields

01 Dec09

Spent some time debugging a strange issue today where input-textfields always contained an undesired extra line. Since I found little info via Google, I’m posting it here for future reference.

If you make a multiline textfield with a border and autoSize set, you’ll see the problem easily. Every time the .htmlText property is set, an extra line is appended. It is not a newline character (\n), but rather a return (\r). This is done by the Flash Player itself and I can’t find a good reason? You can see the bug here (source). I’ve reported the bug in the Flash Player bugbase and initially I had no solution to the bug.

Then, my friend Fabrice found a solution. Adding this line after seting htmlText solves the issue:

tf.htmlText = tf.htmlText.substring(0,tf.htmlText.length-1);

FDT quick tips for Flash Player 10

15 Oct09

Just a quick post to save this somewhere. Two important things when using FDT for Flash Player 10 projects:

  1. Remember to set the target-player parameter in your Compiler Arguments for both the Debug and Run configuration (-target-player=
  2. When using the Embed-tag in FDT, you can’t use the “Pure” config. You have to use the ordinary one

I haven’t seen this noted anywhere and I couldn’t find it on Google. Guess it’s worth posting. Another thing that have bitten me when working with FDT - asset paths require a starting slash like this:

		private var img1:Class;

Another thing that will come in handy is this list of Flex Compiler arguments. FDT does not set/update any of these automatically, so it’s really handy. I keep having mixed feelings about FDT. There’s so many nice things, but all the rough edges seem to ruining my experience of it. I guess I’m just a little spoiled?

BTW: I’ve been really busy lately. Lot’s to catch up on after summer holidays, FOTB, all the MAX announcements (as the iPhone one) and client work. I’ll also go to Sydney to visit my brother next week so it’s been a while since last post. Will probably be so a while ahead as well. So much to do and so much fun ahead!

Please smooth your video site!

31 Aug09

Lately there’s been several great websites that are based on video. We Choose The Moon and Instant Campaign are two of them. Both these sites must have cost thousands of dollars to make, but the video looks quite pixelated. It’s actually so pixelated that it annoys me, especially since it’s so easy to fix. Have a look at the picture below.


Common for both of these sites is that they scale the content to the width of the browser. If you view any of these sites on a big screen such as the Apple 30”, this looks extremely bad and all you need to fix it is one simple line of code:

video.smoothing = true;

That’s it and your video will look much better on big screens. Doing this adds a little to the CPU usage, but this won’t matter much on the average machine.

I’ve also uploaded an example FLA that you can have a look at to test this. Just run the file to load play video. Scale the SWF and click the video to toggle smoothing on/off.

PS: sorry about the lack of updates recently. I’ve been on holidays and been quite busy with client work lately. Finally having a little free time now to experiment and play! :)

AIR window resize inconsistencies

14 May09

The last two weeks I’ve been working on 3 different AIR apps and I have to say I really like Adobe AIR. It’s easy to develop for and quite consistent across the various Operating Systems. One thing that had me (and others) puzzled is how the windowing system works, so I thought I’d add a post for future reference.

There’s two main ways you control the appearance of the main application window. One is by setting properties on the mx:WindowedApplication tag and the other is to set properties in the application.xml file that defines each AIR app.


The application.xml has a xml property that controls the resizing of your app:

<!-- Whether the user can resize the window. Optional. Default true. -->

So to prevent resizing, you just set this parameter to false, right? Not right. You will notice that the “gripper” is still present in the lower, right corner of your app and this allows rescaling. To turn off the gripper, just add showGripper=“false” to your WindowedApplication tag and that’s it. Or is it? Of course not. To make this work with the system chrome, you’ll actually have to turn off the Maximize button as well, making the complete settings like this:

<!-- The type of system chrome to use (either "standard" or "none"). Optional. Default standard. -->
<!-- Whether the window is transparent. Only applicable when systemChrome is none. Optional. Default false. -->
<!-- Whether the window is initially visible. Optional. Default false. -->
<!-- <visible></visible> -->
<!-- Whether the user can minimize the window. Optional. Default true. -->
<!-- <minimizable>false</minimizable> -->
<!-- Whether the user can maximize the window. Optional. Default true. -->
<!-- Whether the user can resize the window. Optional. Default true. -->

The other option is to not use the operating system’s windowing style, but rather the standard one that AIR provides.

<!-- The type of system chrome to use (either "standard" or "none"). Optional. Default standard. -->
<!-- Whether the window is transparent. Only applicable when systemChrome is none. Optional. Default false. -->

These settings will automatically hone the

setting specified in the XML, so the window can’t be resized. You’ll still see the “gripper”, but it won’t have any effect and you can easily turn it off.

The Fullscreen bug

Another, slightly related thing you should be aware of is that there’s a bug relating to using standard window chrome and setting the


properties in the application.xml. If you turn off these properties, they will be grayed out (disabled). Once you set the app to FullScreen mode and return from it, the maximize/minimize buttons are now incorrectly set as enabled allowing the user to set them. Only workaround I know of is to loose the OS native window chrome.

It would be great if this was cleaned up and made more consistent for the next iteration of the AIR runtime. If I turn off the gripper, I want it to disappear (no matter what) and if I set resizable to false, I actually don’t want it to be possible to resize the app, no matter what.

I’d also love to be able set properties such as “Application.application.maximizable” at runtime so I don’t need the XML file at all. It’s really just annoying and messing up my development process.

Note: This post applies to AIR 1.5. I’m not sure, but I think this applies to NativeWindows as well.