Archive for October, 2008


Trackless Slider component

The Slider component is fairly easy to style. But as with many of the flex components, I seem to quickly reach the point where I can’t get it to look exactly as I want it to. Rumours say that this will be rectified in version four, but in the meantime there are workarounds and hacks.

I wanted a Slider component with a background of bars growing in height – like a volume slider. Attaching a png with the bars was easy (yes, I know – it can be scaled. But for this project, scaling was not necessary and I couldn’t justify spending hours on gold-plating it). Removing the tracks wasn’t that easy as it can’t be done through a simple style property.

The solution is a custom skin. But as the Slider component uses the track to calculate some of its properties, and places other graphics according to track size and position, it needs to be measurable. I just drew an invisible rectangle. Overriding the methods that calculate width and height will probably be more efficient, but shouldn’t matter, unless you have dozens on screen simultaneously.

Here’s the skin class – use mySlider.setStyle(“trackSkin”, SliderTrackSkinInvisible) to set it.

package no.papirfly.msp.skins
    import flash.display.Graphics;

    import mx.core.IFlexDisplayObject;
    import mx.skins.halo.SliderTrackSkin;

    public class SliderTrackSkinInvisible extends SliderTrackSkin implements IFlexDisplayObject

        public function SliderTrackSkinInvisible()

        override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void{
            super.updateDisplayList(unscaledWidth, unscaledHeight);

            var gr:Graphics =;
            gr.beginFill(0x00FF00, 0);
            gr.drawRect(0,0, unscaledWidth, height);

Moving files with Ant

Laziness is a virtue. At least the kind of laziness that makes you go “How do I deliver top quality with the least amount of work” as opposed to “I can’t be bothered and I don’t care” laziness

Ant is created by the former type of lazy programmer. For those unfamiliar with it, Ant script lets you script almost anything in Eclipse (and by extension, Flex builder). It can do complex stuff like updating from subversion, compiling etc. Or very simple stuff – which is what I mostly use it for.

I develop on my local drive and need to move the complied release version swf from my computer to our staging/test server. Doing this manually is boring, opening folders and all that. A simple Ant script does the job for me:

<?xml version="1.0" encoding="UTF-8"?>
<project name="movefile" default="main">
    <target name="main" depends="move" description="Move release swf to test-server"/>
    <target name="move">
        <move file="bin-release/myproject.swf" todir="W:\myProjectDirectory"/>

As you can see, it’s a ridiculously simple xml file – just change the file name and destination directory. Right-click and choose Run as: Ant build runs it. After the first run, it will be added to the Run-as menu in the icon bar – looks like a play button with a red toolbox. Which means I can lazily move files with one click.

I use “move” instead of “copy” to ensure that I remember to build a release version every time – if the script is run and there is no file in the release folder, I get an error.

If you use the standalone version of Flex builder, you need to install Ant – see this handy tutorial.


Tabbing and focus in browser problem

(short version: If nested DisplayContainers have a mix of tabChildren states, tabbing from a child at the bottom will yield unwanted results)

We’re porting our Print product from as2 to as3. In that process I had implemented tab navigation in a table element. This was a total nightmare – tab worked beautifully in the flash standalone player, but not in a browser. In both IE and Firefox, hitting tab would change focus to the addess bar of the browser.

Why why why? I read the documentation for the FocusManager as I suspected it had something to do with this – focusManager was a tricky beast in AS2. No answers, so I started reading the actual code in (kudos to Adobe for allowing us to view and debug in the mx.* source code). No answers there either, but a lot of interesting code.

Finally I decided that I needed a more controlled environment to check how the flashPlayer handles tabbing. I created a very simple actionScript project with two editable textFields. This revealed that FP will move focus with tab till it’s at what it perceives as the last element. The tabbing will move focus to the address bar. Next tab will move it back to the first tabbable element in the flash.

So far, so good. But this didn’t answer why I lost focus in my app on every tab. After more hair pulling, I suspected that the tabChildren attribute on DisplayContainer could influence tabbing. I created four Sprite instances, nested them and placed an editable textField at the bottom. Setting all Sprites to tabChildren true or false both gave the correct result, i.e. focus went to the next flash object, not to the browser. But (and this is the finale) if there was a mix of tabChildren=true, tabChildren=false and tabChildren=true, tabbing from textField would send focus to the address bar.  An order of true, true, false, false would work – it was the mix that gave the bug.

After that it was easy to just ensure that the whole chain of DisplayContainers above my textField had tabChildren set to true.


And we’re live

We’ve long wanted to set up a blog to share ideas, opinions and solutions. Mostly regarding Flex and Flash development.

Papirfly is a Norwegian company. We create internet solutions ranging from simple company home pages to complex extranets with lots of custom functionality. We have three flash based products: Print, Banner and Monitor

Print is a WYSIWYG pdf creator. Typical use is job ad creation. The user can edit all content, but visuals are according to graphical guidelines, i.e. you can create ads very fast and maintain brand identity. Much of our flash work is related to writing a framework for the Print templates and also creating the templates themselves.

Banner is a WYSIWYG flash banner-ad creator. The concept is the same as for print: easy to use, hard to mess with brand identity. The end-product .swf files are super-compact and ready to be sent.

Monitor is, surprisingly, also a WYSIWYG solution. It allows content creation for all those nice new flat-screens in lobbies, shops and airports.  Lots of functionality for work-flow and reusing content.

I’ll stop there before this becomes a pure marketing blurb. I’m proud of the work we do, and I know we’re pretty cutting edge in our admittedly narrow field. The point of this blog is that in the daily work of making our products work and work better, we sometimes come across problems that a search on google doesn’t answer. We’d like to share with the community because we’ve so often benefited from similar blog entries, i.e. the times when google searches gave useful results.

October 2008
    Nov »