I know, I know—Flex post?! I have been “drinking the Koolaid” these past few months, but this post is for the greater good. I found a bug and it had me panicking for a few solid hours yesterday. I typically would’ve kept my cool, but with a deadline quickly approaching and the fact that I’m still somewhat new to Flex, it was time to sound the alarms.

First, what’s the bug? It occurs when using multiple item renderers with the List component and changing the dataProvider property. The List should recycle the currently used renderers and choose ones that apply to the new data. Instead, the List tries to use the previous renderers on the new content, regardless of whether they match the data.

I resorted to using some internal resources at Adobe and within minutes had a workaround and bug report, courtesy of Peter DeHaan. Simply, reset the itemRendererFunction each time you change the dataProvider property. I know it’s a bit redundant, but it works and is a temporary solution until the fix is in place. If you’re interested in following the bug, you can watch it on JIRA.

I felt like working on something new this past weekend, so I devoted a few hours to the new AIR 2.0 Beta. One feature that really caught my eye is the NativeProcess class, which allows developers to communicate with the system through an executable. This is a game-changer in the AIR world, opening more doors than you or I can ever imagine. I’ve always wanted screen capture support in AIR, so with this new class, I developed it myself.

Surprisingly, my efforts proved successful!—I had a working class, ScreenCapture, and application, ScreenCaptureDemo, up and running within a few hours. Tired of staring at the Spark components, I decided to add a touch of DT to the app by designing my own skin. This took far longer than the core of the app, but made a world of difference. Now that I think of it, this could be considered my first Flex app.

The downside of the NativeProcess class is it nulls the cross-platform benefit of AIR. The developer must compile a .dmg for Mac, a .exe for Windows, and the choice between a few for Linux. Since I only spent this weekend on the ScreenCapture class and I’m only familiar with the Mac command line, both the class and demo app are Mac-only. Also, the demo won’t work just yet for most of you. It requires a prerelease build of AIR 2.0, but things should be okay once the Beta 2 is out.

Download ScreenCaptureDemo (Mac-only, requires AIR 2.0 prerelease)

Along with adding the ScreenCapture class to DestroyFramework, I created a repository for the ScreenCaptureDemo source and installer on GitHub as well. Check them both out and enjoy!

[note] I’m not quite sure why Vimeo decided to cut out the right audio channel in the screencast…