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.

On October 23 and 25th I will be speaking in Ottawa and Montreal respectively as part of the FlashInTheCan 4 city tour. Then, November 3-5 I will be in Barcelona to speak at the FlashEurope conference. Both of these conferences have a great looking roster of speakers (can’t wait to meet some of the European Flashers I’ve known online but never met, particularly), and should be hella fun.

I’m going to be doing the same talk for both – diverging a bit from my usual semi-dry topics (OOP, OOAD, development process, usability, etc), and doing something a little bit more creative. It should be a lot of fun! My session info follows:

Object Oriented Procrastination

Object Oriented Programming is commonly associated with application development (boring but profitable), but it can also be used to create less practical (and much more entertaining) pieces. This session examines the inspiration, architecture and code of a number of Grant’s recent multimedia experiments. Designers and Flash newcomers will be introduced to the basics of OOP and programmatic motion in ActionScript 2, while more experienced coders will learn architectural best-practices and hopefully be inspired to use their skills for more creative pursuits.

I hope to meet some of you there. Be sure to post in the comments if you’re going to be attending one of these, or if you have ideas for things to do/see in and around Barcelona.

I’m planning to get back to posting, with some new techniques we’ve discovered internally, and some more news on glic over the next week or so… things have just been super-busy! (which is good for business, but bad for blogging)

I’m really happy to announce my latest internal project, named glic (previously Daedalus), or “gskinner lightweight interface components”. My company (gskinner.com) spends a lot of time building rich internet applications, and we grew really tired of working around v2 issues, and explaining major issues like file size and CPU usage to clients, so we finally decided to do something about it, and glic is the result.

Continue reading →