
This article tells the story of how Flash 8 movies learnt to fluently converse with Javascript using the ExternalInterface “API” in XHTML strict.
The ExternalInterface is an ActionScript class that was introduced in Flash 8. It allows a Flash movie to communicate with the Flash Player container using ActionScript code. The Flash Player container is in 99.9% of cases a web page, hence the Flash movie is most often calling Javascript functions, either standard built-in Javascript functions or Javascript functions defined by us, usually in an external *.js file. Using the ExternalInterface class, we’re also able to let Javascript functions invoke ActionScript functions defined in the SWF movie. These Javascript and ActionScript functions can bear arguments and return values, and there can be as many of them existing on both sides of the communication bridge. Let’s keep that in mind.
The communication will fail when :
allowscriptaccess is not set to “always”. (An exception to this is Firefox : testing locally with allowscriptaccess set to “always” won’t work, due to security reasons. In Internet Explorer, if you allow “active content” to be run locally, then you will not run into any problem.) The biggest challenge is certainly to get a handle to the XHTML element in the Document Object Model (DOM) tree that stores the Flash movie. It’s through getting that handle (a handle to an element node) that we can open communication back and fro the Flash Player and our Javascript code. Most Flash books and the Macromedia documentation presents a quick and dirty way for getting such handle, under the cover of “you don't need to understand what's going on here”, a method based on the way Flash “objects" are usually embedded in HTML, using both the object and embed tags. This article provides an alternative method that will have as repercussions that 1- we won’t be shooting in the dark, not understanding what the hell we’re doing, and also that 2- our web page will validate as strict HTML or XHTML.
Comments
Post new comment