Another one of my cast offs from the lab. This one started from a change in development. I’ve started creating more SWC’s within SWC’s rather than a bunch of Shared Libraries; this allows me to compile faster in the later stages of a project. The issue is, unit testing is severly impeeded early in the game, because I’ll usually have one file with all the classes in it vs. a FLA for each class. Therefore, my compile times get worse and worse as time goes on. What I’ve been doing to solve it is make a new FLA, and create a movie clip, fill in the class info, and test that. However, this gets tedious to do over time. Saving a FLA is an option… but I don’t like various versions of my MC’s hanging around since I massage my package (gross) structure early in the game.
So, I figured, why not just creat a quick jsfl script to make a new FLA, create a movie clip, and test it?
…well, it worked in theory…
I quickly found that this solution was only good for classes that didn’t require sub-classes. I always start small, but these things get so big (gross). So, I started adding in logic for defining sub-classes if applicable. However, even though I found some good XUL documetation on the web + using examples from a few extensions I have installed, none of them used code… and the ones that did were not XUL, but instead Flash Panels (a SWF running in a window inside of Flash). I found that a lot of XUL can be scripted with JavaScript, in our case, JSFL. …however, I quickly found the scope is in it’s own memory space. It’s weird; it has references to the app (app/App/fl/flash), and even has references to it’s own XULMI return object, plus any others created, as well as theTool (??? gross???). There was no way I could hack to get a reference back to the original jsfl calling script (the one that called the XUL dialogue). The bottom line was, I could put JSFL code in the button’s oncommand attribute, but it wouldn’t populate the listbox I made, even though it traced out as a valid property.
<button label="Add" oncommand="fl.trace(‘sup’);" />
“Fuggit”, I said as I made a Flash Panel instead. I then ran into another problem; base components. You cannot simply include their classes; you need the base SWF, or in this case, the base SWC file. So, I proceeded to make an interface that allowed you to add those too. A lot of my components use the drawing API, so AS alone is good for the above.
However, my final brick, and fatal wall was fl.componentsPanel.addItemToDocument. That damn function only attaches components to the FLA where the JSFL script was called from, even if you set the new document to focus. I tried everything I could think of (focusing more than once, doing weird things to the document object, saving it, closing it, focusing it 5 times), all to no avail. This test scripts shows an example. Create a FLA, run it twice… it’s always one doc behind…
var doc = fl.createDocument("timeline"); fl.setActiveWindow(doc); fl.componentsPanel.addItemToDocument({x: 0, y: 0}, "UI Components", "Button");
I tried my damndest to figure out a hack, and then just surrendered in defeat. Did I mention I hate losing? Just so we’re clear.
Hopefully, some of you can learn some JSFL/XUL/Flash from this failed attempt at becoming more productive.
File structure is explained in the zip.
Failed Preview Component – ZIP