Last week I gave a presentation at 360|Flex 2010 (San Jose) on “Developing iPhone apps with the Flash Platform.” As always, I wanted to make my slides, notes, reference links, and example code available to those who were there and those who couldn’t make it:

Download slides, links, and example code (3.1 MB .zip)

I’ve been traveling since the conference so I didn’t flesh out my notes as thoroughly as I have for past presentations. If you have a question about a slide, feel free to ask in the comments and I’ll try to explain it better. The 360|Flex folks recorded video of my presentation as well as a screen capture. I believe the plan is to make those recordings available to attendees as well as people who couldn’t make it (though they may charge a fee if you didn’t attend the conference).

Acknowledgments

This is in the slides, but I wanted to once again thank all the people who helped me prepare this presentation (some knowingly, others just by virtue of content they’ve shared):

• Tom Krcha
• Renaun Erickson
• Jeff Swartz
• Aditya Bansod
• Ted Patrick
• Mike Chambers
• Lee Brimelow
• Chiedo Acholonu
• Greg Burch

In one sense, it’s a big bunch of companies partnering with Adobe to make it so that interactive content can be accessed on mobile phones (using Flash Player and eventually Adobe AIR, surprise, surprise). And the content isn’t supposed to be just available, but fully available, using the full capabilities of Flash Player. What? Full Flash Player running on a mobile device? Nobody’s ever complained about that, right? =)

But this isn’t just an announcement of a partnership to think about what may come someday in the future. As part of all of this, Adobe is doing some concrete things today. There are a few things that Adobe’s releasing/changing. The most notable of these to me is that Adobe’s changing the license restrictions on the SWF format (as well as FLV and to allow it to be used not only for creating authoring tools, but players as well. From the FAQ page (emphasis mine):

Publication of an unrestricted SWF file format has long been requested by the Adobe Flash developer community. The longstanding publication of the SWF specification has fostered a vibrant ecosystem of companies and developers who create experiences with Adobe Flash technology and by removing the SWF licensing restrictions we are allowing that growing ecosystem to use the file format for any purpose, including the ability to playback SWF content.

As you may know, for years Adobe (and Macromedia before them) published the SWF format specification, allowing other companies to create tools that generate SWF files. That’s why there are all those “build Flash for free online” sites and packages that hosting companies offer. That’s why Nicholas Cannasse was able to create the awesome MTASC ActionScript 2.0 compiler back when the only way to compile ActionScript was through the Flash authoring tool. Heck, even Adobe used to try to compete with Flash authoring with their LiveMotion product. (Try being the operative word. After all, Macromedia wasn’t dumb. They’d develop Flash version X and Flash Player version X simultaneously, release them both, and only then — a few months later, really — publish the SWF spec. At that point competitors could start working on a competing authoring tool. For people who were targeting a very different market that was okay, but for anyone trying to go head-to-head with Flash? No chance.)

Anyway, the license allowed all of that without any royalties or anything. However, there was a big restriction on the license — if you ever looked at the SWF spec, you could not create an alternative SWF player (i.e. a Flash Player competitor). There’s a compelling reason for this — even though the player has always been free for desktop computers and hence not a direct source of revenue, Macromedia knew that it’s greatest strength was in its “write once, run anywhere” capability. Every web designer knows how horrible it is to try and design a page to look even mostly similar in all browsers — let alone exactly the same. By restricting the creation of alternative SWF players, there is much less chance of alternative “mostly but not completely” compliant players showing up on users’ computers.

Of course, that’s in the past now. As of today the license restriction has been removed, and anyone who wants to can look at the SWF spec and, if they choose, use that knowledge to create an alternative SWF player. (Gnash team I’m looking at you!) In my opinion, for those groups this is the next best thing to Flash Player itself being open-sourced (and maybe better, since that would put them out of a project). While this does have exactly the negative potential I mentioned above, it’s a big deal for device manufacturers. If they bet their future on Flash Player, they don’t want to be stuck if Adobe goes out of business or decides to throw away Flash to focus more on their PostScript printer driver business =) It’s a risk, and I’m crossing my fingers that we don’t get splintered Flash Players all over the place. As others have said, there are some benefits that hopefully outweigh the risks. Fortunately, Flash is a pretty big brand, and Adobe’s definitely not releasing their trademarks on Flash, Flash Player, etc. So anyone who makes an alternative SWF player will not be able to call it Flash anything. (Unless Adobe decides to create a certification program for alternative players or something like that — something which I didn’t see mentioned at all in the project pages.)

For Flash/Flex/AIR developers, honestly I don’t think this project opens any doors immediately, but I think it does have a lot of promise for the future. Currently, it’s pretty hard to create Flash content for a mobile device. You basically have to create a separate version for every device. Many of the devices have Flash Player burned on the ROM, so that player can never be upgraded. If you want to target one of those devices you’re stuck on Flash 4 (tell target lives forever!) When a new version of Flash Lite is released, it takes months before it is added to devices and those devices get into stores and users’ hands.

So a lot of this is about Adobe and other companies working together to make it so that you can use the same code, targeting a player with the same capabilities, no matter whether you’re creating content for a PC or a mobile device. For example, part of the plan is to create a set of “device porting layer APIs for Adobe Flash Player.” In the words of the FAQ, these are “device-specific abstractions of Adobe Flash Player that enable it to work on different operating systems and devices.” Another notable part of the plan is to make it so that the player can be updated just like it can on a PC. Goodness knows I often wish I could update the Flash Player on my Wii!

Plus, the fact that Adobe’s no longer restricting who can create SWF players, and no longer charging royalties to device manufacturers who include Flash Player in their devices, means it will be cheaper, easier, and safer for companies to include Flash Player on their devices, meaning a larger market for content.

Anyway, I was pretty surprised by all of this, and happy for the potential future growth that this could lead to. Adobe’s once again making a big bet, and the payoff will be great for all of us if it works out.

• Security update for Flash Player (“9.4”) (also see the DevNet article)
• Security update for Adobe AIR (“1.0.1”)
• New public Flash Player bugbase (also see the DevNet article)
• Adobe Media Player 1.0 (with a lot more content now that it’s final — if you’ve tried it before but didn’t bother with it because of lack of content, it’s worth another look)

Note: I added AMP after this post was already published, since it wasn’t yet public at the time.

• Deep-linking to frames in Flash websites (Sept. 10, 2007) - for this article I took just one of the techniques I described in the original article and added more background information and better explanations. (I’m sometimes amazed by how much detail I leave out when I’m writing posts on this site!)
• Detecting when data is edited in the DataGrid component (Nov. 12, 2007) - this article was revised much less from the original than the other one. Basically I took the text and found places where I thought it needed more/better/clearer explanation, and added a sentence or revised the text. I definitely think the new version is better, but there isn’t any new information to be had if you read the original.

If you attended the North America MAX 2007 conference or tried to keep up with the news that was pouring out, you probably know that in the day 1 keynote address Emmy Huang and Justin Everett-Church demoed three new features of “Astro” (the “next version” of Flash Player):

• An improved text engine, allowing new capabilities like bi-directional text, re-flowing column text fields, and more.
• The ability to create custom graphic filters, rather than being limited to the built-in set in ActionScript.
• “Postcards in space” 3D transformations that can be applied to display objects to position/rotate them in 3D space.

I think there’s something funny about these three features and the way they’ve chosen to implement them. I didn’t really notice it when I first watched the demo video (no, I wasn’t at MAX), but later it jumped out at me as I was reading some of the responses to the demo in the PaperVision 3D email list, and even more so as I listened to the video interview that Lee Brimelow did with Justin Everett-Church later during MAX, in which Justin clarifies and expands on the three Flash Player features that were described. If you don’t want to jump away to watch the video (although it’s really good for understanding the new features) here’s a transcript of the most important statements Justin makes relating to my idea:

(:29) Justin: “[Astro’s ‘3D effects’ and PaperVision 3D] are kind of fairly different from each other…3D effects is kind of ‘3D for the rest of us’. If you wanted to try and use the 3D effects to do more complicated things there may be some APIs that might help you but you know PaperVision’s an excellent solution, you’re just not going to replace one with the other, they’re going after different objectives.”

(2:40) Lee: “There was a lot [of buzz] around filters and the ability to create your own filters, and we heard ‘Hydra’ mentioned. So what exactly is it? Is it a new programming language?”

Justin: “So Hydra is a new language, it’s a pixel shader language. The Hydra language itself is very consistent with other pixel shader languages…the port between [Hydra and other pixel shader languages] is really easy.”

(4:10) Justin: “So our new text layout engine is really a group of hooks in the Flash Player that are lower level than we’ve ever had before. On top of that we’re building a series of components so they will do things like multi-column flow, inline HTML, bidirectional text, ligatures, lots of complex [?] sorts of things. But those components are developed in ActionScript 3.0 and will be deployed as part of your application. The hooks that are there are going to be exposed to developers so if you want to build your own component, if what we do isn’t exactly suiting your needs then you’ll be able to build a first-class text control.”

Notice that, based on the way Justin describes it, the idea for the improved text engine is that the actual functionality provided by Flash Player/ActionScript is very low-level, and Adobe provides components that give the higher level functionality we expect from a standard text field object (as well as additional enhanced versions).

Think about that for a moment.

Imagine if the flash.text.TextField class, the display object that’s used any time text is displayed in an ActionScript app, were actually a component on top of some lower-level API — and non-Adobe developers could freely write their own version of the TextField class, using those same low-level APIs.

By the same token, imagine if the built-in filters (the flash.filters.* classes) were actually “components” or library classes written on top of some lower-level API. (In fact, I think that’s how lots of developers see them, especially since they all derive from the flash.filters.BitmapFilter base class — with the notable issue that developers can’t create their own BitmapFilter subclasses and use them in ActionScript.) So imagine if you were allowed to create your own BitmapFilter subclass, and Flash Player would use it along with any of the Adobe-provided filters.

Yes, obviously the low-level aspect of the filters involves writing them in Hydra, not in ActionScript, and I really don’t have any idea how that’s all going to get hooked together. Just bear with me — I’m trying to describe big concepts here, not small details =)

Can you see what I’m getting at? That’s exactly what’s happening with two of the three new Flash Player features that were presented at MAX — Adobe is providing a low-level API, much lower than what most developers are going to need to use, and then they’re also providing components or libraries that will be the standard tool that most people will actually use. I think that’s an interesting approach, and one that the advanced developer community is going to really latch on to even while it doesn’t cause any pain or extra work for the typical developer.

However, compare that to the 3D (or 2.5D, as it’s often called) functionality that was shown at MAX. As Justin says, it’s intentionally a high-level API — 3D “for the rest of us” — compared to projects like PaperVision 3D that are working to provide full-fledged 3D modeling, textures, virtual world capabilities, etc. The PaperVision community isn’t so thrilled about this. Naturally they don’t think the player needs a high-level 3D API — they see PaperVision as providing the high-level API, and they’d much rather see the player provide new low-level APIs and/or improved processing power that allows them to do more, better with their higher-level APIs. (I’m paraphrasing and probably mis-describing this to some extent, since by I am by no means a 3D expert or even intermediate-level developer.)

As another aside, it occurs to me that the idea that Flash Player APIs are “high level functionality provided by the Flash Player team written in ActionScript” isn’t actually new. It’s a well-known fact that a notable amount of the Flash Player functionality is actually written in ActionScript and not in C++ or C or assembler code. In those cases the only difference between the built-in functionality and an external ActionScript library that you or I write is that the ActionScript code comes pre-installed in Flash Player and doesn’t have to be part of a SWF file download. An interesting historical note related to this is the history of the XML class (the old-school one that lives on as flash.xml.XMLDocument). The XML class was introduced in Flash Player 5, and in that release it was written entirely in ActionScript and consequently suffered from some speed issues in how it parsed XML. The ActionScript developer community (Branden Hall, I believe) wrote an alternative implementation known as XMLNitro that was faster than the built-in one. Back then in ActionScript 1, it was fairly straightforward to “redefine” methods of the built-in classes so that the player used your own ActionScript code instead, so that’s what many people did to get faster XML parsing. Funny, isn’t it, that with the newer constructs added in ActionScript 2.0 and ActionScript 3.0, we’ve also lost some functionality — namely the ability to overwrite built-in functionality with our own code. That was definitely a low-level capability that was previously available in Flash Player.

Interestingly, even in modern (i.e. post Adobe-Macromedia merger) history this idea of “low level APIs with higher-level components on top for normal use” isn’t completely new in “Astro”. One obvious precedent is the Flex framework; however, the example I’m thinking of is part of the Flash authoring tool. Historically Flash authoring was released simultaneously with new versions of Flash Player, and consequently there were always new authoring tool features that corresponded to new player features (obvious example: the filters and blend modes that were added in Flash 8 to Flash authoring as visual tools and to Flash Player as ActionScript APIs). Interestingly, however, in Flash CS3 there were some authoring tool features that were added that didn’t have a corresponding player API. Specifically I’m referring to the “copy motion as ActionScript” feature that allows you to select a tween sequence on the timeline and copy it “as ActionScript” — the animation becomes ActionScript code that you can paste somewhere and use to re-create the animation programmatically. What I think is notable about that authoring tool functionality is that the pasted code doesn’t work as-is via a player API — rather, it requires some external ActionScript libraries that were included with Flash CS3 (the fl.motion.* and fl.transitions.* packages). So the functionality underlying that feature of Flash CS3, one of the headline features of the product (created by none other than Robert Penner), was completely independent of the core Flash Player APIs and was instead provided by an external library.

Think about it this way: the Flash authoring tool team wanted to include functionality that wasn’t provided in core Flash Player ActionScript. It was specifically a “high level” type of functionality — simple scripted animation. Other people have written their own APIs to do the same thing, using the ActionScript “low level” APIs (display object properties, enterFrame events, etc.) and the Flash authoring “high level” approach does the same thing — it provides a library of code to simplify a certain task, so that users can easily create the effects they want, within the limitations of the high level library. I see this as another existing example of this idea of core ActionScript providing low-level functionality, with third parties and also Adobe providing high-level functionality in the form of ActionScript libraries that build on top of that low-level functionality.

Now, going into the future, there is a new Flash Player feature that allows the player to cache certain Adobe-approved code libraries, so the user downloads them once and then they’ve got them for every future site they visit that uses the same library. We’ve heard that the Flex framework is going to be the first such “cacheable” library. However, if this feature had existed earlier it could obviously have been used for the ActionScript classes that are used to support the Flash CS3 simplified animation (“copy motion”) functionality. For that matter, the Flash CS3 UI components could be given the same treatment and be available as a cacheable library, although that might be less necessary by virtue of their “intentionally lightweight” design.

While I really can’t say for sure, it seems like it’s not a stretch that the new text components would be distributed this way, especially since, as Justin points out, “those components are developed in ActionScript 3.0 and will be deployed as part of your application.”

I think that, going into the future, this is a potential direction I can see Flash Player and ActionScript moving in:

• Flash Player/core ActionScript provides low-level APIs
• Adobe provides components or libraries written in ActionScript that provide high-level-enough (“medium-level”?) functionality such that most common use cases and functionality are provided for. Probably these components/libraries are external, player-cacheable code libraries rather than part of Flash Player itself.
• Third-party developers can likewise create their own components and libraries that either build on the Adobe-provided components/libraries or provide alternate implementations.

Of course, the obvious exception to this way of working is the new 3D effects, which are very high level and are essentially the end user functionality, rather than providing low-level building blocks on which Adobe and/or third party developers can build more robust libraries.

What do you think of this future? Does it sound good, or scary? I’d love to hear your thoughts on this one…

Disclaimer: While I am an Adobe employee, I actually had very little knowledge of these “Astro” features until watching the MAX keynote presentation. I had heard general descriptions of some of them, but certainly nothing like the level of detail that was given by Emmy and Justin in the keynote and follow-up interview. Likewise, since then I haven’t gotten any additional “insider” information about these or other future Flash Player features. Obviously some of what I say in this post is speculation about the future, and I readily admit that it is indeed speculation and nothing more — I don’t have insider knowledge on this, and I might be completely wrong about all of it. =)

Now, if you or someone you know is a Flash designer with almost-none-to-basic ActionScript experience, and you want to learn ActionScript from the established master, you can do it for free. Adobe is sponsoring a free, one-day ActionScript training course given by Colin Moock that’s traveling around the U.S. (and eventually the world) starting in October 2007.

They’re calling it “Colin Moock’s ActionScript 3.0: From the Ground Up Tour.” And you shouldn’t feel intimidated if you are just getting started with ActionScript — the site explicitly says it’s not for advanced developers, so if you’re just getting going (i.e. you’ve done some frame scripts but not anything with classes) you should be in your element.

Currently it looks like there are stops scheduled in San Francisco, Los Angeles, and New York City. Even if you don’t live in one of those areas, think of it this way — for only the price of travel you’re getting an awesome training experience.

(via Stefan Gruenwedel)

Suppose you’re creating a user interface with Flash CS3, using the new lightweight ActionScript 3.0 components. You’re using the DataGrid component to display — what else — a table of data. You want users to be able to edit the data, and you want to know when the user changes the data so that you can update the application.

For example, suppose you’re building something like this simple spreadsheet application:

Naturally, when the user edits a value in the “quantity” column, you’d expect the “Total” value to automatically update.

This sounds like something that should be built in to the DataGrid component, doesn’t it? Alas when I started down the road of trying to figure out how to make it work, while building the Filter Workbench example for Programming ActionScript 3.0, I discovered that it’s not quite as straightforward as I had hoped.

In this article I’ll start with some discussion of what I tried that didn’t work, then follow up with two different approaches that do work (each of which has tradeoffs):

• What doesn’t work — using DataProvider events

• What does work (with help) — using DataGrid events

  • Using two different event listener functions (less convoluted)
  • Using one event listener function (more convoluted)

What doesn’t work — using the DataProvider’s events

I started digging through the documentation, and I noticed that the fl.data.DataProvider class (which I was using as the data source for my DataGrid) has some interesting looking events, dataChange and preDataChange. “Ah-ha!” I thought. I can just add a listener for those events, and when the DataGrid changes the underlying data in the DataProvider, it will dispatch those events and (if I need it, which I didn’t) I can grab a snapshot of the old data in preDataChange and get the new data in dataChange. (In fact, in my case I didn’t even need to know which data had changed — it was sufficient for my purposes to know that some data had changed, and then I just recalculated filter values using all the data in the DataGrid.)

Unfortunately, that’s not how the DataProvider works. In fact, its events are designed to handle the opposite use case — i.e. if something other than the DataGrid changes the data in the DataProvider, then the DataProvider notifies the DataGrid so that it can update itself, but if the DataGrid changes the DataProvider, the DataProvider assumes that the DataGrid already knows about the change (and nobody else would want to) so it doesn’t dispatch its events in that case.

So, strike 1 for trying to use the DataProvider’s events.

What does work (with help) — using the DataGrid’s events

Since the DataProvider was out, I had no choice but to look at the DataGrid’s events.

The DataGrid exposes one event, itemEditEnd, that looks like it might be useful. However, there are a couple of problems:

1. The itemEditEnd event is dispatched every time cell editing ends — not just when the cell’s data changes. So the fact that the event is dispatched doesn’t automatically tell us that the data has changed.
2. Unlike the DataGrid’s itemEditBegin event, which has a corresponding itemEditBeginning event, the itemEditEnd event doesn’t have a corresponding event that you can use to get the value before it is edited (in fact itemEditEnd, in most cases, gives you the value before it is changed, whether or not it actually changes).
3. The event object dispatched by the itemEditEnd event is a fl.events.DataGridEvent. That class doesn’t have any property such as dataChanged or oldValue and newValue, so I didn’t see any obvious way to identify whether the data had changed. (The DataGridEvent class does have some properties that end up being useful — but nothing that can be used without some work.)

Eventually, however, after stepping through the source code of the DataGrid several times as it processed editing events, I was able to figure out a couple of ways that you can identify when an edited item’s value has changed in an editable DataGrid.

The premise behind both of these approaches is this: Normally when you register a listener for the DataGrid’s itemEditEnd event, the underlying data in the DataProvider still contains the old values, and hasn’t been updated by the DataGrid. In fact, the DataGrid itself updates the DataProvider by registering for its own itemEditEnd event, then checking whether the original value is different than the new value, and updating the DataProvider it that’s the case. The question is, if the DataGrid is updating the underlying data as part of handling the itemEditEnd event, how can we get the value both before and after it changes, so we can compare them and see if it’s changed?

Using two event listener functions

This is the approach I recommend, although it does require more code (because you have to write two event listener functions). The trick behind this approach is the concept of event priority.

As I mentioned above, the DataGrid itself uses its own itemEditEnd event to update its DataProvider. If you consider the conceptual model of how events work in ActionScript 3.0, basically when a user ends the item editing process (probably by clicking or tabbing away from a particular cell), the DataGrid loops through the list of objects that have registered as listeners for the itemEditEnd event, calling each function in turn. Since the DataGrid uses itemEditEnd to update its DataProvider, that could theoretically lead to inconsistent results. Depending on whether your particular listener function is called before or after the DataGrid’s internal itemEditEnd listener function, the value in the DataProvider may or may not be updated with the new value.

In order to prevent this potential problem, the DataGrid uses event priority to specify that it should be called after most of its event listeners — which is the reason why (in the normal case) the DataProvider contains the pre-edit data rather than the new value (if any). Specifically, when the DataGrid registers as a listener of its own itemEditEnd event, it does so using a priority of -50. Here is the actual code, from line 679 of the DataGrid class’s source code:

addEventListener(DataGridEvent.ITEM_EDIT_END, itemEditorItemEditEndHandler, false, -50);

When you register an event listener in ActionScript, you can optionally specify a priority for your listener (the default, which most listeners use, is 0). Listeners with a higher priority get called first, and listeners with a lower priority get called later. Since the default priority, that’s rarely changed, is 0, any listeners that are registered using the default will get called before the DataGrid’s internal itemEditEnd listener — so they’ll get access to the pre-change value.

However, there’s no reason that your event listener can’t register with a different priority. For that matter, you can register two different listener functions for the same event, with different priorities, which is exactly how this approach works.

You register two functions as listeners for the DataGrid’s itemEditEnd event. The first one should be called before the DataGrid updates the DataProvider, so it must be registered with a priority greater than -50 (I use 100 here):

// This variable will store a temporary value
// to check if the DataGrid's edited item changes
var tempValue:Number;

// register itemEditEnd listener that will be called before an item's value is updated
myGrid.addEventListener(DataGridEvent.ITEM_EDIT_END, itemEditPreEnd, false, 100);

function itemEditPreEnd(event:DataGridEvent):void
{
   // get a reference to the datagrid
   var grid:DataGrid = event.target as DataGrid;
   // get a reference to the name of the property in the
   // underlying object corresponding to the cell that's being edited
   var field:String = event.dataField;
   // get a reference to the row number (the index in the
   // dataprovider of the row that's being edited
   var row:Number = Number(event.rowIndex);

   if (grid != null)
   {
      // gets the value (pre-edit) from the grid's dataprovider
      tempValue = grid.dataProvider.getItemAt(row)[field];
      // you could also use this line to get the value
      // directly from the cellrenderer that's showing the value
      // in the datagrid -- it's the same value.
      // That way you wouldn't need a reference to the DataGrid.
      //tempValue = event.itemRenderer.data[field];
   }
}

The second listener should be called after the DataGrid updates its DataProvider, so it must be registered with a priority less than -50 (I use -100 here):

// register itemEditEnd listener that will be called after an item's value is updated
myGrid.addEventListener(DataGridEvent.ITEM_EDIT_END, itemEditPostEnd, false, -100);

function itemEditPostEnd(event:DataGridEvent):void
{
   var grid:DataGrid = event.target as DataGrid;
   var field:String = event.dataField;
   var row:Number = Number(event.rowIndex);
   if (grid != null)
   {
      // gets the value (post-edit) from the grid's dataprovider
      var newValue:Number = grid.dataProvider.getItemAt(row)[field];
      // you could also use this line to get the value
      // directly from the cellrenderer that's showing the value
      // in the datagrid -- it's the same value.
      // That way you wouldn't need a reference to the DataGrid.
      //var newValue = event.itemRenderer.data[field];

      // check if the value has changed
      if (newValue != tempValue)
      {
          // do actions that should happen when the data changes
      }
   }
}

Notice that in the first listener function (itemEditPreEnd) the function stores the current value in a persistent variable (a variable which is declared outside the function scope). In the second listener function (itemEditPostEnd) that stored value is compared to the final value, and if they’re different we know that the value of the edited item actually changed.

Here’s a working example of this approach:

Using one event listener function

Although I recommend the other approach, if you don’t like the idea of using two listeners for some reason, or if you’re concerned about using the semi-hack of using two different priorities, there is an alternative approach that uses only one event listener.

In this approach, you create a single listener function, and register it with a priority greater than -50 (the default 0 is fine). I repeat, your listener must be triggered before the DataGrid updates the DataProvider, or else you’ll get a runtime error.

This approach works by pulling values from two different places. For the pre-change value, it looks in the DataProvider (or optionally in the cellrenderer for the cell, as shown above). For the post-change value, it actually looks at the DataGrid’s itemEditorInstance property, which is the actual display object that’s used for the editing field, and pulls the raw data from there (basically, it reads the text property of the TextField that’s used in the default item editor). Where it gets complicated is that it has to dynamically determine the name of the property that’s used by the item editor. That way, if you create a DataGrid that uses a custom item editor (e.g. if you have numeric data in a column and use a NumericStepper whenever that column is being edited, rather than the default text field) then you’ll need to know the name of that item editor’s property from which you should get the edited value.

Here’s what the code looks like:

// register itemEditEnd listener to determine when an item is changed
myGrid.addEventListener(DataGridEvent.ITEM_EDIT_END, itemEditEndHandler);

function itemEditEndHandler(event:DataGridEvent):void
{
   // get a reference to the datagrid
   var grid:DataGrid = event.target as DataGrid;
   // get a reference to the name of the property in the
   // underlying object corresponding to the cell that's being edited
   var field:String = event.dataField;
   // get a reference to the row number (the index in the
   // dataprovider of the row that's being edited
   var row:Number = Number(event.rowIndex);
   // get a reference to the column number of
   // the cell that's being edited
   var col:int = event.columnIndex;

   if (grid != null)
   {
      // gets the value (pre-edit) from the grid's dataprovider
      var oldValue:Number = Number(grid.dataProvider.getItemAt(row)[field]);
      // you could also use this line to get the value
      // directly from the cellrenderer that's showing the value
      // in the datagrid -- it's the same value.
      // That way you wouldn't need a reference to the DataGrid.
      //var oldValue = event.itemRenderer.data[field];

      // get the value (post-edit) from the item editor
      var newValue:Number = Number(grid.itemEditorInstance[grid.columns[col].editorDataField]);

      // check if the value has changed
      if (newValue != oldValue)
      {
         // do actions that should happen when the data changes

         // Note that in this case, the dataprovider
         // hasn't been updated yet, so you can't do any
         // actions that require the dataprovider to have
         // the new data
      }
   }
}

In fact, if you already know for certain what type of object is being used as the item editor, you don’t need to use such convoluted code. For example, with the default item editor, grid.columns[col].editorDataField will always be “text” (the .text property) so you can just use code like this to get the post-edit value:

var newValue:Number = Number(grid.itemEditorInstance.text);

And of course, if you’re using some custom item editor, you can just hard-code the appropriate property name. For example, if you’re using a NumericStepper instead of the default item editor, you can use “value” instead of “text”:

var newValue:Number = grid.itemEditorInstance.value;

Note the biggest drawback to this approach, as explained in the comments: the DataProvider hasn’t been updated by the DataGrid yet, so if you want to do anything using the DataProvider this approach won’t work (unless you use some technique to delay your actions until after the DataGrid has updated its DataProvider). As stated previously, you can’t use this technique after the DataGrid has updated the DataProvider; if you try to, you will not be able to get the pre-edit value (because the DataProvider will have already changed) and you’ll get a runtime exception (because the item editor will have already been destroyed, so you won’t be able to access it anymore to get the new value).

Here’s a working example of this approach (it looks the same as the previous one, of course):

Extra

Download the examples from this article (1.1MB .zip — as usual, a FLA with components is BIG).

• Anne Zelenka: “Why Open is Good and How Open Could Be Good for Flash” (and it’s predecessor, linked to from that article).
• Ted Leung: “Adobe wants to be the Microsoft of the Web” (and its followup article, linked at the bottom)
• Ryan Stewart: “How Adobe can overcome the issues around open sourcing the Flash Player” (he previously stated that Adobe shouldn’t open source Flash Player, so this is an interesting article with some new ideas I hadn’t seen before.)

Anyway, if you’re interested in this topic, the following links may be useful to you:

• A Slides (with lots of notes!) and example files/code (271 KB .zip)
• A recording of the presentation, in case you want to actually hear what I had to say =)

As always, feel free to add a comment or contact me if you have any questions or thoughts.

There are many attempts to loading external swf into cfform… But what about the contrary? Do you know a way to embed cfform into a flash movie? i.e. call a cfform in a movieclip without getURL and external pop-up ..

I started writing a comment response, but naturally it was getting pretty long-winded so I decided it deserved its own posting.

When you use cfform in a coldfusion page, the server generates a SWF file, with its own URL. (I don’t know whether it actually writes it to the disk, or whether it just keeps it in it’s memory — but from the end-user perspective that doesn’t really matter.) More specifically, it generates a SWF, then sends the appropriate HTML to the browser including the URL of the SWF. From the browser’s perspective the SWF is a completely separate item at a different URL — the browser doesn’t know that the programmer wrote it all in a single document. You can see the generated SWF’s URL by looking at the HTML source code of the CFM page.

For example, consider the page at the following URL (an example accompanying an article by the folks at ASFusion):

http://www.asfusion.com/blog/examples/cfdj/

If you view the source, you’ll see that the page includes some JavaScript that is used to write the appropriate object and embed tags into the browser page. Right in the middle of that you’ll see this line (today at least; the file name may change in the future, as explained below):

document.write("   src='/blog/examples/cfdj/859792312.mxml.cfswf' ");

That’s the line of JavaScript that’s writing the SWF’s generated URL into the page. So we know that there is a URL that the web server will recognize and, when a computer requests that URL, the server will return the appropriate SWF.

You can try it out if you’d like — try requesting the SWF’s URL directly (i.e. http://www.asfusion.com/blog/examples/cfdj/859792312.mxml.cfswf) and you’ll see the same SWF, without the HTML page wrapper.

So, knowing the URL of the generated SWF, you can use it in the same way you’d use any SWF. As I mentioned, you can type the URL in the browser to request it directly, or you could alternatively load it into another SWF using MovieClip.loadMovie() or any other MovieClip loading technique (e.g. the Loader class in ActionScript 3.0).

Potential issues

There are, of course, a couple of gotchas that you’ll want to keep in mind.

1. First of all, notice that the generated SWF’s URL is really just a number with a couple of file extensions. The reason for that is because this generated URL represents a single version of your cfform SWF. If you change the source code of the cfform in such a way that it needs to recompile the SWF, then the server will generate a new SWF with a new URL. So any time you change your cfform, the URL will change too (and, obviously, you’ll need to change the URL that’s called by the other SWF doing the loading). The reason the URL changes is to prevent the browser from using the cached (old) SWF — with a new URL, the browser loads a new SWF.

   An obvious workaround is to just make a copy of the generated SWF and put it at a permanent URL. Like I said, I’m not sure if ColdFusion actually writes the generated SWF to the server’s hard drive, or whether it just keeps it in memory. If it does write it to disk it should be easy to get a copy from the server. If not, you can just load the SWF directly in a browser and then choose “Save As…” (or whatever) from your browser to save a copy of the SWF locally. BUT, by using a single URL, you lose the automatic versioning that prevents the browser from caching the SWF. You can find one idea to work around that issue (i.e. to do your own SWF versioning) in my article “Using URL Variables and FlashVars” (specifically the URL Variables part of the article).

2. Second (and this is a big one): From my rudimentary tests, it looks like any queries in the CF page that the cfform uses are not available when you load the SWF separate from the CFM page. I’m not sure why — I’d have to look more at the generated MXML to try to figure it out — but my guess is that the SWF makes use of the URL of its container HTML page to figure out where to communicate to get its data (rather than having the CFM page’s URL hard-coded into the SWF). Depending on what you want to use the cfform for, that probably throws a big wrench into things.
3. If you’re actually using the cfform for its intended purpose — that is, as a form to submit data — you’re going to have some issues with loading it into another SWF. When you submit a cf flash form, it navigates away from the current URL to the cfform tag’s “target” URL (essentially using LoadVars.send(), so clicking that button on a cfform SWF loaded into another SWF would navigate away from the container SWF as well.

Finally, I can’t help but mention that loading a cfform SWF into another SWF may be a case of over-complicating something that can be done better in other ways. The obvious alternative is to just use Flex directly to create the form SWF, then loading the Flex SWF into the other SWF. Naturally, that means you’ll need to learn Flex…but if you’ve used cf flash forms then you’re already well on your way into that territory — just write out the generated mxml and take a look at what it consists of; then change a few things in the cfform and see how that changes the generated mxml…and so on. Don’t get me wrong — I’m sure there are legitimate reasons for using cfform rather than Flex in this situation, and I obviously can’t predict all the use cases. But over the long run I think you’ll find it’s a lot easier, without any of the issues or side effects, to use Flex.

The library is still in ActionScript 2.0—I haven’t finished porting it to ActionScript 3.0 yet, although I’ve started.

This release (.3 beta) contains a single bug fix. In anticipation of porting the library over to ActionScript 3.0, I wrote a series of unit tests, and—what do you know—I found a bug in the code that parses date values returned from an XML-RPC service call. I guess unit tests really are useful for ActionScript =).

I also added a new project history page and a new step-by-step example of how to make an XML-RPC call, in response to some user feedback and questions.

I got an email from “Brent” asking me if it’s possible to give someone a url that links directly to a particular keyframe of a Flash application:

Maybe you can tell me if this is possible or not, I have a feeling it’s not cause i’ve been searching through google and not finding anything written about it. Can you target a specific keyframe in a flash movie through an HTML page link (possibly using PHP? or javascript to feed the info to flash?) The reason for doing this would be if, for instance you had a flash site with different sections and wanted to give someone a link to your contact section without having them navigate to it…

is this possible?

Indeed, it is possible.

There are a few ways to accomplish what Brent was asking about. In fancy buzzword circles they might call it “using REST with Flash” or “creating RESTful urls that work with Flash”, or something like that (the key term being “REST”, which means having distinct urls for direct-linking to different states of a web-based application).

I. Using Flash’s frame anchors

The first way is one you can do within Flash itself, without needing any ActionScript. You can assign “anchors” to keyframes on the timeline. If you’re familiar with adding frame labels to frames, it works pretty much the same way:

1. Select the keyframe you want to be able to target
2. In the Property inspector enter the anchor text (the text that will be added to the url to link to the particular frame) in the “<Frame Label>” field
3. In the “Label type” drop-down choose “Anchor”
4. Finally, to make it work you have to open File > Publish Settings, and in the HTML tab, in the Template field, choose “Flash with Named Anchors”

To link directly to a particular keyframe, just use this format: “html_page_name.html#anchor_name” (replacing “anchor_name” with whatever name you gave the keyframe in step 2 above).

Admittedly I’ve never used this in production. I did a quick test and it seemed to work fine in Firefox 2.0 and Internet Explorer 6; but I couldn’t say if it will work in other browsers.

Also note that if you want to use frame labels (e.g. for ActionScript navigation) and anchors on the same frame #, you need to create them separately. In other words, you need a keyframe on one layer at that frame with the frame label, and another keyframe on another layer of the same frame with the anchor.

II. Using FlashVars and server-side code (url variables)

For a more involved (but well-tested) approach, you could use FlashVars with PHP to pass in the url. Basically you would make your html page url look something like this:

html_page.php?section=profile

The value that you pass in to the “section” variable could be a frame label, or just a value that you’re going to use in ActionScript somehow.

Then in the actual php source, in the part of the HTML that embeds Flash Player, you’d put something like this in:

<object ...>
<param name="FlashVars" value="section=<?php echo($_GET['section']) ?>" />
...
<embed ... flashvars="section=<?php echo($_GET['section']) ?>" />
</object>

(Note, I’m just writing this php from memory, and it’s been a while since I did php, so I may be putting the wrong thing there — but hopefully you get the idea).

If you’re using one of the JavaScript libraries for embedding the SWF, such as SWFObject or Adobe’s Active Content technique, those libraries already have built-in functionality for FlashVars, so you should be able to find examples of how you’d add the FlashVars with those libraries.

Anyway, that’s the HTML/PHP side of things. Back in Flash, on Frame 1 of the main timeline you’d add code like this:

this.gotoAndStop(section);

The variable named section is ‘magically’ created by Flash Player, as a result of the FlashVars code that was written into the html by php.

For more on FlashVars, you can see this post I wrote a while ago:

Using URL Variables and FlashVars

And you can see these slides/notes from a presentation I gave to an Adobe users’ group covering FlashVars and related techniques:

Slides and notes from “Flash to external data communication”

III. Using Kevin Lynch’s technique for making linkable Flash applications

Finally, there’s an even more complex but fancy and re-usable approach that was shared by Kevin Lynch, formerly of Macromedia and now Chief Software Architect for Adobe. It’s more involved code-wise, but it’s pretty slick:

Making Rich Internet Apps Web-Friendly

This technique (like the first one) doesn’t require anything special on the server — it uses JavaScript and ActionScript to do all the work. The advantage it has is that it updates the url in the browser window as you navigate around in the Flash SWF — so that not only can you have urls that link to different application states, but it’s easy and obvious to discover what those urls are.

The book is “Macromedia Flash 8 Advanced: Visual QuickPro Guide” (Peachpit Press), by Russell Chun and me.

The chapter is chapter 2, “Working with Video.” It covers converting video to FLV format (in depth), adding Flash elements/overlays/controls to a video, and rotoscoping with Flash video.

The chapter has been released as part of the sample eBook Library that Adobe has released in conjunction with the beta preview of the Adobe Digital Editions eBook reader. You can download the chapter from the Sample eBook Library page (you may need to install the reader first — I’m not sure since I had already installed it before I went to the library page).

Note: based on some helpful feedback the code was revised on Oct. 30, 2006 to be more cross-platform-friendly.

As a followup to a question about opening local and remote resources in ActionScript, I was asked why a SWF which had been made into a projector (a standalone executable file) wasn’t able to open an HTML page using getURL() when the user’s default browser is Firefox. One initial idea was that it might be related to the security restrictions added in Flash Player 8, which (by default) make it so a SWF which is running off a user’s local computer can only access local resources or network resources, but not both. However, as the documentation points out, a SWF which has been published as an executable file isn’t subject to the same restrictions. (And I actually tested it out to confirm that’s the case.)

So here’s the situation: imagine you’re creating a SWF file to use as a menu on a CD-ROM. It will have several buttons, some of which will open HTML pages that are also on the CD-ROM. That sounds easy enough—using the getURL() function in ActionScript 2 (or the equivalent flash.net.navigateToURL() function in ActionScript 3.0), you can specify a relative url (basically just the file name) of the HTML page you want to open, and when the user clicks the button, Flash Player hands the url off to the operating system and the HTML page is opened in the user’s default browser. So if you want to open a file named “test.html” which is at the same level in the file system as the SWF executable, you would use this code (ActionScript 2):

// assume the button's instance name is myButton

myButton.onRelease = function()
{
    getURL("test.html", "_blank");
};

or this code (ActionScript 3.0):

// assume the button's name is myButton

import flash.events.MouseEvent;
import flash.net.*;

function openPage(event:MouseEvent):void
{
    var request:URLRequest = new URLRequest("test.html");
    navigateToURL(request, "_blank");
}

myButton.addEventListener(MouseEvent.CLICK, openPage);

Assuming the user’s default browser is Internet Explorer (or a version of Netscape/Mozilla prior to the ones based on Firefox), this works as you would expect it to: the user clicks the button, and the page “test.html” opens in the browser.

However, if the user’s default browser is Firefox (or, I suspect, one of the recent Netscape versions based on Firefox) then the page does not open. Instead, one of a few possible things happens. On my system, Firefox opens with two tabs. The first tab is blank, and the second contains a security warning (something about not being able to change the location of the My Documents folder). This is very possibly because I was testing it from my hard drive, rather than from a CD-ROM drive. On other people’s systems, from what I’ve heard, the browser opens with a blank tab and a tab which is the result of a Google “I’m feeling lucky” search based on the name of the file (which is the default action when you enter keywords rather than a valid url in the browser’s address bar).

Note: this problem isn’t just limited to getURL() — it also applies to other methods which load a url, such as LoadVars.send().

So what’s going on, and more importantly, how do we make it work so that we can use SWF menus to open web pages on a CD-ROM? After doing a little research, I learned first of all that Adobe is aware of the situation, and that in fact it’s not a Flash Player bug at all. It turns out that this is due to a Firefox bug (well, an out-of-control feature) based on how Firefox handles a url which is passed to it as a command-line parameter.

According to the bug report, when you call Firefox on the command line, you can pass it multiple urls separated by pipe (|) characters and it will open each one in a separate tab. So if you issue a command like this:

firefox -url "http://www.yahoo.com/|http://www.google.com/"

Firefox opens a new browser window, with Yahoo in one tab and Google in another.

Going back to Flash Player, when you call the getURL()/navigateToURL() function with a relative url (something like “test.html”), Flash Player actually constructs an absolute url which is what it passes to the browser. So when our code says getURL("test.html", "_blank"), Flash Player turns that into something like this in the (Windows) operating system:

firefox -url "file:///d|assets\test.html"

Notice the magical pipe character (|) where you or I would probably put a colon (i.e. “file:///d:\assets\test.html”). The pipe syntax is legal—Firefox just assumes that a colon will be used instead. So when Flash Player constructs an absolute url and sends it to Firefox, Firefox sees the pipe character and says “hey, they want me to open two tabs, the first with the url “file:///d” and the second with the url “assets\test.html”. Hence we see a browser window with two tabs, with the second containing the result of a Google search for “assets\test.html”.

Note: according to the same bug report, this has been fixed for the “Deer Park” version of Firefox, which I believe is Firefox 2.0, so once that browser is out and spread throughout the world, this won’t be as much of an issue. But I won’t be holding my breath…

Interestingly, on the ActionScript end of things the problem stems from the fact that Flash Player is constructing an absolute url to send to the browser, and that url contains a pipe character. When you specify an absolute url in your getURL()/navigateToURL() call, Flash Player just passes that url to the browser unmodified. Of course that’s what we’d expect for a remote web address, like “http://www.google.com/”, but it works just the same for local “file:///” urls. So to work around the Firefox bug, what we really need to do is construct the absolute url ourselves in ActionScript, and use that url (which, again, will get passed to the browser unmodified). The big question, of course, is how we can figure out the absolute path of a file on a CD-ROM when we don’t necessarily know the drive letter of the user’s CD-ROM drive.

Fortunately, ActionScript comes to our rescue. Every MovieClip object (every DisplayObject in AS3) knows the url it was loaded from. You can access this as the _url property in ActionScript 2, or as the url property of the DisplayObject’s loaderInfo property in ActionScript 3.0. Usually, for a SWF in a web page, this will be the url of the SWF file, of course, but when a SWF is running locally (even when it’s in an executable/projector) that property contains an absolute “file:///” url with the path of the SWF file on the file system. For example, consider this code, on a keyframe on the main timeline, running in a SWF projector (an EXE file) on a CD-ROM:

// Assumes there's a dynamic text field on the stage named output_txt

// AS2
output_txt.text = this._url; // output_txt contains "file:///E|/assets/trial.exe"

// AS3
output_txt.text = this.loaderInfo.url; // output_txt contains "file:///E|/assets/trial.exe"

Going back to our SWF CD-ROM menu example, if the HTML page we want to open is in the same folder as the SWF projector, we can just generate our own absolute url by getting the SWF’s url, chopping off the name of the SWF, replacing the “|” with a colon, and adding the name of the HTML page. (Or, for a more complex case, we can use the SWF’s url to determine the “base” url, and then use that to generate absolute urls for files in other folders etc.)

Here is the code for a working version of this (ActionScript 2):

// code on a keyframe on the main timeline

var swfUrl:String = _root._url;
var lastSlashIndex:Number = swfUrl.lastIndexOf("/");
var pipeIndex:Number = swfUrl.indexOf("|");
var baseUrl:String;
if (pipeIndex >= 0)
{
    baseUrl = swfUrl.substring(0, pipeIndex);
    baseUrl += ":";
}
else
{
    baseUrl = "";
}
baseUrl += swfUrl.substring(pipeIndex + 1, lastSlashIndex + 1);

myButton.onRelease = function()
{
    var targetUrl:String = baseUrl + "test.html";
    getURL(targetUrl, "_blank");
};

And here’s a working version in ActionScript 3.0:

// code on a keyframe on the main timeline

import flash.events.MouseEvent;
import flash.net.*;

output_txt.text = this.loaderInfo.url;

var swfUrl:String = this.root.loaderInfo.url;
var lastSlashIndex:Number = swfUrl.lastIndexOf("/");
var pipeIndex:Number = swfUrl.indexOf("|");
var baseUrl:String;
if (pipeIndex >= 0)
{
    baseUrl = swfUrl.substring(0, pipeIndex);
    baseUrl += ":";
}
else
{
    baseUrl = "";
}
baseUrl += swfUrl.substring(pipeIndex + 1, lastSlashIndex + 1);

function gotoTestHtml(event:MouseEvent):void
{
    var targetUrl:URLRequest = new URLRequest(baseUrl + "test.html");
    navigateToURL(targetUrl, "_blank");
}

myButton.addEventListener(MouseEvent.CLICK, gotoTestHtml);

Of course for the AS3 version you could use regular expressions for the finding and replacing—but in this case it’s simple enough, and perhaps more efficient, to not use them.

If you’d like to try it out for yourself, you can download FLAs for these two versions (45 KB .zip).

By request, I’ve also made a version of the FLA in Flash MX 2004 format (31 KB .zip).

I have a question. You say that in your presentation “[When they’re running locally,] SWF files are set to load local files only or remote files only — if you want to load the other type, it won’t work and you’ll get an error message. There are several workarounds, …”

Can you share the work around for this problem? I used the executable file (instead of swf) but it even gave errors when I had local and remote files to load. The browser should be always open when the file is running. Is there a way to make it run?

(Incidentally, the question was from one of my former classmates from the Indiana University Instructional Systems Technology program.)

The workarounds depend a little bit on what you’re trying to accomplish.

If you want your locally-running SWF to load remote files only, the easiest solution is to change the publish settings for the movie. Under File > Publish Settings, in the Flash Tab, in the “Local playback security” field (the last field) choose “Access network only”.

However, it sounds like you want your SWF to be able to load remote files and local files, which makes things more complicated. What you’ll need to do is to designate the file or a location on the user’s hard drive as a “trusted” file/location. When files are trusted, Flash Player will let you access both local and remote content. There are three approaches to making this work:

1. Designate the SWF as “trusted” in the Flash Player settings.
   This only works if it’s running in a browser — it sounds like you converted your SWF into an executable, so I don’t think this one will work in that situation.

   This approach is outlined here:
   LiveDocs “Specifying trusted files using the Settings Manager”

2. Designate the folder containing the SWF (or some higher-up folder) as “trusted” in the Flash Player settings.
   This is the same as the previous approach, except that you designate an entire folder as trusted, so you could use one SWF to designate a folder as trusted, and put another SWF in there and it will automatically be trusted too.

   This approach is also outlined at:
   LiveDocs “Specifying trusted files using the Settings Manager”

3. Designate the folder containing the SWF (or some higher-up folder) as “trusted” in the local configuration file.
   This achieves the same end result as 2) (an entire folder, and all its contents, are “trusted”). The difference is that this approach involves creating or modifying a configuration file on the user’s computer, so it can be done without needing to access the Internet at all.

   This approach is described here:
   LiveDocs “Creating configuration files for Flash development”

Interestingly, if you are in fact creating an executable containing your SWF and the Flash Player, you shouldn’t have any problems at all, according to this document (LiveDocs “About local file security and projector files”). It says that executables are automatically “trusted” since the user explicitly chooses to run them, so they should be able to access local and remote files. I made a simple test which seemed to confirm this:

1. Open a new FLA and add a button (instance name myButton) and a dynamic text field (instance name myTextField) to the stage.
2. Enter this code, attached to a keyframe on frame 1 of the main timeline:

   var myLoadVars:LoadVars = new LoadVars();
   
   myLoadVars.onLoad = function(success:Boolean)
   {
        myTextField.text = "myLoadVars.value1 = " + myLoadVars.value1 + "\n";
       getURL("http://www.adobe.com/");
   };
   
   myButton.onRelease = function()
   {
       myLoadVars.load("LocalSecurityTest.txt");
   };

3. Save the FLA to your hard drive (I just put mine on the desktop)
4. In the folder where you saved your FLA, create a new text file named “LocalSecurityTest.txt”, and enter this text in the text file (then save and close):
   value1=Hello+There!
5. Under File > Publish Settings, check the “Windows Projector” checkbox, and click Publish.
6. Double-click the executable and click the button. This text should appear in the text field: “myLoadVars.value1 = Hello There!” then it should open a browser window to “www.adobe.com”. (Loading the text file data is a “local” operation; loading a url in a browser is a “network” operation).

If you publish an HTML/SWF version, open the html page and click the button; the text file data will load then you’ll see a security warning about accessing network content. (Alternatively, if you publish the SWF as network only, the text file data won’t load so you’ll see “myLoadVars.value1 = undefined” in the text field and the browser will navigate to www.adobe.com).

]]> http://probertson.com/articles/2006/10/06/local-remote-resources-local-swf/feed/ 8