There are no two ways about it: Flash MX 2004 is a powerful development environment for creating fun and engaging applications. Yet, there comes a time when you may need a little more control of system-related functions such as being able to detect the operating system the user is using, launching external programs, detecting default file handling applications and controlling system windows -- especially when creating distributed applications.
When you are looking to create educational reference material, presentations, CD-ROMs or complicated applications, Flash will (depending on the complexity of the project) usually fulfil the needs of the brief. But there are times when Flash on its own just doesn't cut the mustard, and needs a little more horsepower to accomplish the desired effect.
In this article, we'll look at how, by integrating Flash and Director, we can query the operating system on which the application runs, return information and make decisions based on that data.
The information presented in this article should give you the inspiration to explore the possibilities of Flash and Director integration, and give you a taste of what you can achieve with a little imagination and flair.
Example Scenario
You are building an application in Flash that needs to open several different file types (spreadsheets, PDFs, presentations, executables etc), but in order to make the application as smooth as possible, you need to check for the existence of applications that handle the types of files you are trying to open, and act accordingly.
Using Flash to check whether there is a registered file-handling application for a given file that you're trying to open is, to my mind, extremely difficult -- if not impossible -- without third party or bespoke integration tools.
…Enter Stage Left: Director MX /MX 2004!
I was recently working on a project for a CD-ROM application, and decided to create the interface in Flash. There were several sections of the application that needed to open PDF files, and I included a link to the Adobe Acrobat Reader that was included on the CD-ROM. Everything was working fine, until the client decided to add features to the project, which included opening multiple document types.
Of course, this presented a new problem: I needed to know and inform the user of whether they had installed the application required to open the document they'd selected, and Flash just wasn't up to the job on its own.
Rather than scrapping what I'd already written, I decided to investigate other methods by which I might retrieve this information, and found Director MX 2004 to be the prime candidate for the job.
How It Fits Together
The solution that I came up with was a meld of Flash and Director, where I used Flash to create the interface and act as the 'stub' to call functions within the Director application, which, in turn, was using an Xtra to perform a series of functions.
While I researched alternative methods for retrieving the information, I came across a Director Xtra called 'Buddy API', which contains over 140 functions for interfacing with the Windows API and Macintosh Toolbox.
This was the perfect Xtra for the job and, although it is a commercial Xtra, the unregistered free version includes two free functions. The Xtra contains many functions, some more useful than others. Click here for more details.
Luckily, I could use the unregistered version, as I only needed two functions from the Xtra:
FindApp: Finds the application associated with a file type
OpenFile: Opens a file using its associated program
Essentially, the Flash movie is embedded within a director application, and, rather than producing a Flash projector, we produce a Director Projector that interfaces with the operating system via the Director Xtra to check certain criteria, then carry out specific functions.
The flow of information from the Flash interface through Director projector for this example is outlined in the diagram below; while it's simple, let's take a quick look at the steps involved and how the two applications communicate.
Step 1 In the embedded Flash interface, the user clicks a button (in the example shown below, it's named openPDFDoco) which calls a defined function within the Director application in the following format:
openPDFDoco.onRelease = function() {
getURL('lingo:FunctionHandler.FunctionName(Parameters)');
};
Step 2 The parameters of the file (name, extension, type) are passed to the Director movie and a custom function is called, which checks via the Buddy API Xtra whether a file handler is present for the file we wish to open.
Step 3 The Buddy API Xtra checks to see if a file handler is present using the FindApp("file type") function and returns a true or false value to the Director Projector.
Step 4 Based upon whether a file handler is present, the file is opened using the OpenFile(filename, windowSize) function of Buddy API (step 5).
Step 5 The file handler is verified and the file is opened in the relevant application.
Step 6 If the File Handler is not found for the file we are trying to open, we can either trigger an alert within the Director projector to inform the user, or we can call a function in Flash.
Step 7 We call the function to be executed at a specific frame in Flash; this could be as simple as moving the playhead to a specific frame to inform the user of the missing application for the file they're trying to open.
By planning the behavior and integration of both the Flash SWF and the Director Projector, we can have the best of both worlds -- an easy-to-maintain application with a powerful interface that's capable of many different tasks.
In the example shown below, I've implemented this methodology to create a distributable Director projector. This serves as an installer for an application -- both as a Macromedia Extension Manager file (*.mxp) and as PDF documentation (*.pdf) -- but the basic idea outlined here can be used for any number of different projects when you need expand the capabilities of Flash.
to refer the origine article please visit http://www.sitepoint.com/article/flash-director-mx-2004
