I was excited to see that FlashMagazine has a review of 6 popular projector tools. I have the occassional need to create a full-screen projector, and I’ve always found the process slightly irritating, at least with the older versions the tools. Why? Because the extra commands are not available within the authoring environment; they require that you output a .SWF file that is then processed with the projector-maker tool to create the .EXE. And, most of them (with the exception of mProjector) require callbacks or polling functions to tell when the command has actually executed. This makes for aggravating code development.

Based on the article, I’m going to have to take another look at mProjector and SWF Studio 3.0.

mProjector has the advantage of synchronous commands, but when I was evaluating it a year ago I found the documentation incomplete regarding features I was trying to use: window control and accessing other OS features outside of Flash Player. The docs claimed it was possible, but for the life of me I couldn’t get any of it to work. I also found the SWF conversion tool to not be very reliable about providing feedback on whether it was working or not, as I was adding various mComponents into the projector. Since debugging with these projector tools is kind of blind, it just increased the feeling that the whole development process was overly-finicky. As it turned out, there was some odd slowdown I experienced with one flash movie. The developers were responsive and clarified a lot of things for me, but I wasn’t able to get that Flash movie to work right and had to drop the entire line of inquiry due to time.

I haven’t tried any of the versions of SWF Studio; the fscommand-based nature of the product turned me off, so I tried mProjector first. It looks like it would be similar in development workflow.

What would be nice to have in a projector tool

• Direct Integration into the Flash IDE? These tools patch their code into the projector somehow to provide access to the new objects. According to Darron Schall, these tools work by wrapping the ActiveX control in a native window. I imagine the IDE version of the player must be integrated into the environment in such a way that it’s un-hookable. That SharpFlash project might have some useful mineable code in it.

• Piggybacking code onto an existing author-time Flash Player DLL? Would it be possible to wrap a DLL that’s accessed by the IDE’s version of Flash Player, and hook in some additional features? Then provide an AS 2.0 class to present a nice face to the world, hiding the potential ickiness of the hack? Some things may not work well in the authoring environment though (full-screen modes comes to mind).

• How about an IDE Tool? Short of integration into the IDE, how about just providing some convenient method of doing the conversion? I just peeked briefly at the JSAPI, which allows you to add extensions to the authoring environment. There is an API for writing in C, and you can apparently add new commands to the JSAPI that could at least help with automatic launching of a SWF-to-EXE tool. To use the JSAPI, you create a JavascriptFlash (.JSFL) file and store it in a magic directory: see the Macromedia Javascript Dictionary‘s overview section.

  It seems that you can create DLLs that add on to the Flash JSAPI DOM, which sounds promising. Unfortunately this is not directly accessible by runtime Actionscript, as JSAPI applies only to the Flash Authoring Environment, not the Player. From what I can tell, the functionality in JSAPI is also limited to manipulating the standard Flash objects, so it’s more useful for generating effects and stuff like that.

• Or go 3rd Party MTASC? If you’re going to have to run some third party app anyway, maybe just use Eclipse and MTASC to get things done. A command-line version of the SWF-to-EXE tools would then be very nice, as you could just add that to your MAKE file. The disadvantage of this approach is not being able to use the Flash IDE to do animation and graphics; not a big deal for pure Actionscript 2.0 projects.