Yesterday marked one year of blogging for me – and man has the time ever flown past. A lot has happened on the blog and off:

• 102 posts to the blog
• 500 comments
• over 1 million visits to gskinner.com
• Macromedia FlashMX 2004 released
• speaking at a bunch of events about OOP, usability, development process, etc
• developing and successfully running my 3 day Flash MX 2004 Enterprise Development workshop
• gskinner.com growing from just me to 5 full time (super-capable) people
• meeting and speaking with a ton of very cool, very intelligent members of the Flash community
• working on some amazing projects with some truly awesome clients (thanks guys!)
• constantly expanding my knowledge and capabilities with Flash, OOP and general project/client/business management
• … and a whole ton of other stuff (stopping myself before this gets really long)

The past year did not see the launch of gskinner.com version 3, or gModeler 2, but we’ve been amazingly busy, not least of all with the gskinner lightweight interface components (glic) which should be coming out soon.

It’s been an awesome year, and I’d like to offer my sincere thanks to everyone who helped make it so. My very lovely girlfriend (who is EXCEPTIONALLY patient), family, friends, co-workers, fellow Flashers, clients, readers, etc).

I hope to keep the ball rolling, so if you have suggestions, comments (what did you like or not like on the site), criticisms, or encouragement please let me know in the comments below.

Cheers everyone!

I mentioned in a previous post that we have developed standards for assigning linkage IDs here at gskinner.com, and a few people expressed interest in them so here’s a quick post to explain our two main standards, and a JSFL script to help keep your library nicely organized.

Continue reading →

I’ve just updated my JSFL batch compiler. It will now also output any compiling errors to the log file (though it can’t detect them outright, so the error message might not show if your only errors are compiling errors generated by Flash). Thanks to Keith Peters (bit101) for the heads up on outputPanel.save()!

I also made the logging a little easier to read, and fixed the title on the file selection dialog, just special for Stacey (aka BitchWhoCodes).

You can download the latest by clicking here. Documentation is here.

Continue reading →

One of our current projects has over 50 FLAs, all of which need to be compiled, and organized into the proper directories on a regular basis. I got bored of trying to remember what had to be compiled, and doing it all manually, so I wrote a simple JSFL script that compiles and moves them all for me (it also does other interesting stuff, like update import linkage URLs depending on whether I’m doing a production or dev build, but more on that later). It also generates a handy-dandy log of the process.

I thought this might be useful for other people, so I spent a bit of time making it more generic and easy to use. Here are some instructions on how to use it – you can download the script and a simple usage demo at the end of this post.

Continue reading →

One of the major limitations of setting up large dynamic applications in Flash MX 2004 is that most of your content (and hence most of your file size) gets dumped onto frame 1. This is especially true if you use a lot of Macromedia components.

There are a number of workarounds for this, including setting up an external file to handle pre-loading, but the best one I have found is to carefully move all of the content off of the first few frames, so that you can set up a proper preloader within the swf in the first two frames.

There are a number of steps to achieving this – I will walk through each of them, and you can download a simple demo at the end of this entry.

Continue reading →

Even though Flash MX 2004 has been out for nearly a year, I never took the time to really look at JSFL until a couple of days ago. Two things convinced me to play with it, the introduction of the JSFL File API in 7.2, and a huge project that had a lot of opportunities for JSFL streamlining.

Now that I’m into it, I’m a junky – JSFL kicks serious butt! After only a couple hours, I had already knocked out a bunch of scripts that help me streamline development, and I have a bunch of ideas for new ones in the very near future. Among the finished scripts are:

1) A script that automates the task of setting up an FLA for internal pre-loading – it walks through the library, turns off “export on frame 1”, and places an instance of exported clips onto a specified frame. I will be releasing this one with instructions for use later today or tomorrow.

2) A script that batch compiles, renames and moves FLAs. I’ll be making this script a little more generic and safe, then releasing it with instructions later this week.

3) JSFL that organizes the library according to linkage ids – we use very strict rules for assigning linkages at gskinner.com, so this script will clean up the library based on those ids. If you’re interested in this one, let me know in the comments and I’ll write up a blog entry on our linkage rules, and the JSFL itself.

NOTE: I would definitely urge a dose of caution when it comes to JSFL. The File API is extremely useful, but it also has the potential to be used maliciously. It is extremely simple to write a JSFL script that deletes critical files (intentionally or unintentionally). Pair this with the fact that JSFL files execute when double clicked, instead of opening to be edited, and you have a potentially dangerous situation. I would definitely urge MM to swap this behaviour in the next release of Flash – when I double click a JSFL, it should open to edit, so that I can review it’s functionality prior to running it (it’s way too easy to dbl-click by accident when you want to edit it).

Anyway, definitely more info on this coming soon, including some cool stuff related to gModeler. I’ll also be posting on the status of glic before too long.

Chris Pelsor pointed me to this Ask Slashdot article on “Online Replacements for Desktop Apps”. Interesting read (at least in places, but such is Slashdot), but I found it strange how few of the RIAs Slashdotters know of are Flash-based. My gModeler app made it as the first app mentioned (yay, I’ve been slashdotted), but most of the other examples people posted were Java or or DHTML.

I wonder if this is simply indicative of Slashdot mentality (which naturally tends towards open-source and standards), or a wider public view.