It seems a “London/Cambridge-based Actionscript developer” posted an excellent tutorial for ActionScript 2.0 and AsUnit.

Just wanted to make sure folks could find it!

Over the years, Ali and I have spent quite a lot of time trying to sort out when to use static classes, when to use the Singleton pattern and when to do the work required to avoid them.

There has been a long and ongoing discussion in the OOP and patterns community on this subject by people far more intelligent and experienced than I am. It is really their knowledge and experience that will be essentially repackaged for ActionScript development here.

Following are the primary arguments that compel me to look for a better way.

UPDATE: The new versions of Sprouts actually pull down and install the Flex SDK automatically!

UPDATE: AsProject has been refactored, renamed and moved, development is ongoing at the new location for “Sprouts”.

I’m elated to finally announce AsProject!

This is a cross platform, open source ActionScript development tool set that I’ve been working on for the past couple of months.

AsProject automates a variety of tasks including the creation of projects, classes, test cases, test suites, and swfmill libraries. It automates the download, installation and configuration of the debug flash player and many open source tools. AsProject also includes sophisticated build tools written in rake to automate build processes.

If this sounds interesting to you check out the video demo!

I’m sure there is an easier way to make this happen, but I was really glad to hear that someone figured out how to get our XUL UI utility running on MAC OSX!

Many thanks to David Drescher for working through this and posting the results of his efforts to the list, following is what he found:

—-—-—-8<-—-—-—

I’ve been messing around with getting the XUL ui working in os x 10.4 and I thought I would pass what I learned on to anyone who’s interested:

It looks like with the new 1.8.0.4 release of XULRunner won’t let you start up the asunit ui from the command line. Instead you now have to use the xulrunner-bin binary to first install the application from the terminal:

$ xulrunner-bin—install-app /path/to/XULUI-Mac/

This creates a folder /Applications/asunit/ which contains a new asunit.app os x application folder. You can now just double click on the application to launch the ui.

(note: the xulrunner-bin binary can be found in /Library/Frameworks/XUL.framework/ once you’ve installed XULRunner).

It should be possible to use the provided application structure to create a standalone mac app to distribute via dmg if you also include the XULRunner framework.

-Dave

—-—-—->8-—-—-—

Hopefully we’ll have a simpler binary soon, but in lieu of that, this should at least help the Mac folks get some traction.

Thanks Dave!

Wow…

I was just doing some work on event handling with AsUnit 3.x and discovered something pretty strange. It seems that if an event handler throws an exception, there is no way to catch it from the initiating thread. For some reason, if an exception makes it to the EventDispatcher, it just passes right through all encountered catch/finally blocks and goes right up to the player as an uncaught exception.

Just copy the following code into a new ActionScript project in FlexBuilder and make it your default application to see this in action:

package {
    import flash.display.Sprite;
    import flash.errors.IllegalOperationError;
    import flash.events.Event;
    import flash.events.EventDispatcher;
    import flash.events.IEventDispatcher;

    public class EventDispatcherTest extends Sprite {

        private var dispatcher:IEventDispatcher;

        public function EventDispatcherTest() {
            runTests();
        }

        public function runTests():void {
            dispatcher = new EventDispatcher();
            dispatcher.addEventListener(Event.CHANGE, someHandler);
            try {
                // Uncomment this line to see the catch work...
                //someHandler(new Event(Event.CHANGE));
                dispatcher.dispatchEvent(new Event(Event.CHANGE));
            }
            catch(error:*) {
                trace("Exception has been caught!");
            }
        }

        private function someHandler(event:Event):void {
            trace("someHandler called");
            throw new IllegalOperationError("AnyException");
        }
    }
}

This will throw an exception up to the player with a call stack that looks like this:

Error: AnyException
    at EventDispatcherTest/EventDispatcherTest::someHandler()[...EventDispatcherTest\EventDispatcherTest.as:31]
    at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
    at flash.events::EventDispatcher/dispatchEvent()
    at EventDispatcherTest/runTests()[...EventDispatcherTest\EventDispatcherTest.as:22]
    at EventDispatcherTest$iinit()[...EventDispatcherTest\EventDispatcherTest.as:13]

You can see from the call stack that the exception actually passed through the “runTests” method – but didn’t get caught!

I’m really not sure what to make of this, but I think we’re about to have to roll our own event management!

Those of you using AsUnit 3.x should know that because of this issue, the old recommended way of testing event handlers in AS 2 by throwing an “AssertionPassedError” won’t work in AS 3.

Anyone else run into this? Perhaps there is something simple that we can do differently to avoid this behavior?