3 year-old prototype bit me

I was having problems with the mx.formatters.CurrencyFormatter in Flex. It takes a number or string, and formats it to look like currency. For example, 1.2567878 can be made to look like $1.25. For some reason, it was not working in my DataGrid and I had no idea why. I built some test cases, files that have nothing but a TextInput and a formatter, and they worked so I was really having a challenge figuring out why. Then, it worked when I ran the app in debug mode in Flex Builder 1.5, but didn’t work in normal mode.

Three hours later, it turns out some code written in 2003 for our debugger was overwriting String.prototype.toString. Since the mx.formatters.NumberBase, does a:

return value.toString()

The modified toString function was munging the results. No debug code in your app, no problem.

Anyway, I really like protoypes. They allow a lot of meta-programming concepts to be done, and really help those creating languages to have the developers build the future API for you based on what they overwrite, just like we did with Flash 5 & 6 in ActionScript 1. I think there is still a lot of room for growth for tools to take advantage of prototype features at compile time, and build upon some of those runtime goodies.

Adobe Flex 2 Ad, FMUG Breezo, and Sparkle Doesn’t Suck

I’m catching up on the hilarity that can be gained by bequeathing anyone & everyone with a digital video camera and internet access over at Ebaum’s World last Friday evening and spot this Adobe ad on the right side.

You can attribute that to Adobe’s influx of marketting dollars vs. Macromedia‘s, attitude towards spending for advertising, or just plain luck. Regardless of the cause, you gotta admit that fuggin’ rocks!

BTW, if you’re bored, I’m fixin’ to speak about Flex 2 for the Flash and Multimedia Users Group of Arizona in 30 minutes (10:00pm eastern, GMT -5) via this Breeze link. Nevermind, rescheduled; I’ll blog the new time.

Oh yeah, and Sparkle doesn’t suck like Brandon Hall makes it sound. He’s just in love with his loosely typed ActionScript 1.0 and ability to play extremely well workflow-wise with his designer & partner in arms, Joshua Davis. Consider the source I say.

It’s atually neat! They just need to drastically improve the timeline, and I need to learn C# to back up my claims that it doesn’t suck since the real power is in the API.

ActionScript 3: Void is now void

One small gotcha in the Flex 2 Beta 1 build that a lot of ActionScript coders may get caught up on. Make sure your Void’s, usually used at the end of a function that returns squat, are changed to void. Note the lowercase “v”.

So this:

protected function hello():Void

Becomes this:

protected function hello():void

Calling Functions Repeatedly in ActionScript 2 & 3: setInterval, setTimeout, and Timer

Pre-ActionScript 3, Flash could use setInterval. This method allows you to have a function called at a recurring time frame. So, you could have a “hello” function called ever 3 seconds.

setInterval(hello, 3 * 1000);
setInterval(someScope, "hello", 3 * 1000);

Both forms invoke the function “hello” every 3 seconds. I personally always used the 2nd form to avoid any weird scope issues and EXTREMELY easier to debug; there is no confusion over what scope the function is being invoked in.

You can stop the interval from calling your function over and over by clearing it. All intervals created return ID’s, which are a unique number identifying the interval. If you want to clear an interval, you have to keep the number around to clear it later. This number is returned when you call setInterval.

theID = setInterval(this, "hello", 3 * 1000);

Intervals are dangerous. If you forget to clear one, it can continue running in the background, leading to memory leaks and performance issues. Since there is no visual indication for intervals that do not call GUI related functions, and the API for them is small, they are hard to track down.

The 2 main ways to ensure in ActionScript 2 that you never have problems is to always call clearInterval right before you call setInterval with the same ID, or use Kenny’s interval management class.

Flash Player 8 introduced the setTimeout function. Most uses of setInterval were really for delaying the calling of functions. Because Flash is all about events, and programming in it is very asyncronous in nature, one tends to adopt the calling of functions in a similair fashion; you wait for other things to happen before you yourself call functions rather than immediately. Such as waiting for the screen to refresh, giving a CPU intensive operation additional time to cool down, or launching a hyperlink when your content is loaded. There are some issues in using it in a class, and it was mysteriously not documented, but Guy has some good info on it’s usage in the comments. You can also clear a timeout just like clearInterval via clearTimeout.

As of Flash Player 8.5, and thus ActionScript 3, setTimeout is relegated to being depreciated already. Damn… that function only lasted HALF a player version. That’s a first.

Both setInterval & setTimeout were moved to the flash.util.* package.

The new class to use for both use cases, repeatedly called functions and post-poned one shots, is the Timer class, also defined in the flash.util package. Both intervals and timeouts tended to pollute your class in their usage, more so intervals than timeouts. You usually had to not only keep a property that held your interval id, but also all the management code for making sure the interval was cleared, mixing both the function that’s run and the interval management in one.

Now that Timer is it’s own class, this is a lot cleaner. On the flip-side, it knows nothing of your code, however, so it’s up to you to call the function, which actually adds more de-coupling; you can choose to call the function or not, and still let the timer continue running. Or, you can just do it the old fashioned way, and have the listener function BE the function you want called.

One thing I don’t really like about it however is its name; it’s not really a Timer in the general sense of the word because it isn’t timing anything, at least that it exposes to you. Rather, it’s more of a beacon, and fires off just 1 event, “timer”. Granted, you could use the Timer class to create a timer.

Here’s a code snippet example from the docs commented:

// create a timer with a 1 second
// delay, that fires twice
var myTimer:Timer = new Timer(1000, 2);
// have your onTimer function listen
// for the timer event
myTimer.addEventListener("timer", onTimer);
// unlike an interval & timeout,
// she doesn't start ticking
// until you start it
// this function will run twice,
// every second,
// starting 1 second after you call start
function onTimer(event:TimerEvent)
        trace("onTimer: " + event);

The 2nd parameter to Timer, and also a public property, is the repeat count. This allows finer grained control on how many times the timer event is generated. You can set it to 1, 20, or 4,294,967,295 times… which would take 7 weeks assuming your function took 0 milliseconds to run.

What’s special about it, though, is 2 things. First, you can set it to 0, which is infinity. Basically, it’ll keep going until you stop it.

Second, it’s a public, writable property. Meaning, you can change the speed it goes WHILE it’s going, or while it’s stopped.

This goes for the delay as well. It, too, is a public property that you can change, speeding up or slowing down the running timer.

Frankly, I don’t think setTimeout is deprecated as they say it is. It feels a lot more elegant to me to just use 1 function to make an intentionally prolonged function call. Still, Timer is a, if not aptly named, pretty bad ass new class.