This is something I’ve been wanting to do for quite some time.
Many moons ago, I created a simple GUI for asdoc.exe (the tool that creates nice looking HTML documentation from actionscript class files for those wondering – though I can’t imagine anyone reading this and not knowing) using SWFKit. Well, it was about the same time that Apollo first appeared (or maybe it was AIR beta 1 by that time – who can remember), and I thought it would be great to convert the whole project into an AIR application. It didn’t take long, though, to discover that AIR was not capable of launching applications in their native habitats, so that ended that. Then back in January, Mike Chambers published a means of integrating AIR with C-Sharp thereby gaining a closer OS relationship. This would let you do things like launch applications and take screen shots straight from AIR.
Finally, four and half months later, I got the time to “play around” and test out this intriguing proof of concept. And so enters ASDoc GUI version 2.0 – this time created in Flash/AIR but, thanks to CommandProxy, capable of launching asdoc.exe.
You can see some screenshots below.
You can download the project here, but because this was only a test of Mike Chambers’ concept, I didn’t bother building a custom installer and manual installation, while not wildly difficult, may be a bit tricky.
To install:
- Download the .zip file here and extract to wherever desired.
- Install the ASDocGUI.air file (requires latest version of AIR runtime to be installed), but don’t run it (well, you can go ahead and run it if you want to. It won’t break anything – but it won’t work, either).
- Navigate to the installation directory (on Windows that’s C:\Program Files\ASDocGUI by default) and drop in the GUILauncher.exe file. GUILauncher.exe and ASDocGUI.exe should reside in the same directory.
- Now simply run GUILauncher.exe – it will automatically launch the AIR application and you’re in business. If you desire a shortcut on your desktop (or anywhere else) make sure it’s a shortcut to GUILauncher.exe.
The above instructions also come in a readme.txt file included in the .zip.
A few things to consider:
This isn’t the prettiest application ever created. Because this was all just a test of Mike Chambers’ ideas I didn’t do much beautification. The design is simple as heck. The GUILauncher.exe will run at the same time as the AIR app. Don’t close it, it’s necessary and will also provide a little feedback about what’s going on inside a console window. Speaking of feedback, expect little to none. The application works fine when all goes well, but when it doesn’t go so well, it will fail silently. Make sure you know generally what you’re doing as far as asdoc commands and expectations are concerned. If I get a bit of positive feedback, I just may make a more user friendly version. It works fine for what I use it for, however, and it certainly served its purpose demonstrating the CommandProxy concept.
Speaking of which, the CommandProxy concept is, first of all, very simple to put into effect. I believe the largest amount of development time went into creating an Accordion component (which I will post at a later date after I clean up and better document the code as it’s now a part of my ui package). I see no reason why Adobe should not implement a similar .api in AIR itself in a later release. I understand that security is a concern, however, other .swf wrappers (Zinc, SWFKit, etc) have been doing these types of things for years. I see no reason why Adobe shouldn’t hop on board and really utilize it’s own technologies to the fullest extent.
By the way, if anyone tries this out with a MAC, please post a comment. I’m curious to hear the results.
For more information on the CommandProxy “Proof-of-Concept”, get it straight from the horse’s mouth.