That’s right, one of the master Flash game makers, Jobe Makar, has released the source + presentation notes he did at Flash Forward San Fran. Uses ElectroServer with server-side ActionScript.
P.S. Gregg Wygonik: You were p0wned by my backdoor attack!
For JSAPI/JSFL code, skip to bottom.
The problem with using Shared Libraries without an SWC is that each and every element of the shared swf needs to be exported to that shared swf. That way, when you use it in another FLA, its assets are not duplicated in the other SWF. This is one reason making shared libraries with the Flash MX framework was very diffucult compared to the Flash MX 2004 one. Since all Flash MX 2004 built in components are SWC’s (excluding the support class for Alert), it is very easy to make them shared libraries.
In Central, however, your linkage URL for your symbols, if your using shared libraries (which you have to for the built in Central components) is dependant on the URL that your hosting your Central application at. So, instead of exporting a custom Slider component to “Slider.swf” for your Clock app, you’d instead type “http://www.yourserver.com/clock/Slider.swf” for the Shared Library URL.
I’m in the process of finding a suitable new host for my website. As such, my directory structure is changing as I implement more organization in my filing structure to cope with the increasing amount of files I have to manage for my site. As I quickly found, right clicking on dozens of items in the library for each shared swf’s symbol blew major chunks. So, I made a quick JSFL script to do this for me via a undocumented feature that Vera posted about.
There are 2 scripts. The first shows the linkageURL property for all items in your library.
The second will allow you to set all assets to the same linkageURL with one click. Simply type in the url in the prompt window, and click ok. Whatever you type in the prompt field will be what all items in the library have their linkage URL set to, assuming they are exported for runtime sharing. Naturally, you wouldn’t want to run this script on the main.fla, or any other FLA that uses multi-tired libraries (has multiple shared SWF’s in it). The way to circumvent this problem is to update the main SWF’s using this scirpt, and then right click on the symbols in the FLA that uses different shared assets, and click the update option. This should update their linkage URL properties based on the FLA they come from.
There is some more error checking and beutifying that could be done, but I’ll leave that up to someone who has the time. If you wish to have them appear in your Flash MX 2004 commands menu, place these files in:
C:\Program Files\Macromedia\Flash MX 2004\en\First Run\Commands
Or whatever is closest.
*** Warning: Save your file before you use this. I’m not to be held responsible for foobarring (screwing up) your file. You have been warned. ***
Thanks Vera!
Don’t know if I’m allowed to post, so rather than be sorry later, I’ll just explain what I did as it’s pretty easy to repeat.
Manager needed to compile app last week, so I had to convert all the AS2 to AS1. The main issue was EventDispatcher… <strike>he</strike> she was written in a pattern/manner that I was not familiar with. So, I just started hacking to see what worked.
I first put everything on _global, instead of the functions in a class definition. Since the majority of the methods were static (Singleton’ish?), I just put those methods straight on the classes, AS1 style (_global.EventDispatcher.initialize).
Second, I deleted all the first 4 lines in the initialize function.
So far, <strike>she</strike> he works great!
That insanely smart Canuck (at least, I think he’s a Canuck; <a href=”http://www.gskinner.com/blog/archives/000065.html”>too cute not to be</a>), <a href=”http://www.gskinner.com/blog/”>Grant Skinner</a>, has <a href=”http://www.gskinner.com/blog/archives/000069.html”>posted</a> a neat way to utilize el activation object to quickly and easily scope your XML objects (LoadVars same way). Nestled in composition ‘esque classes, this is a great way to wire your XML document’s callback to your class so it can call a custom parsing method, etc. Better yet, if you place a var in front of the creation of the XML object, he’ll die when garbage collection comes along (supposedly).
However, I don’t agree this is a best practice. Course, nothing in Flash is really documented as such, most Flashers just generally agree and double check with Java peeps to ensure we can feel good about our decision to do so.