by Grant Skinner

IE Active Content Changes

Everyone and their mother will be blogging this, but for good reason – this is an important issue, and one we have to start addressing sooner rather than later.

Information on the changes to how Internet Explorer handles active content (like Flash and Shockwave) is now available at:

http://msdn.microsoft.com/ieupdate

http://www.macromedia.com/devnet/activecontent

It’s better than it could have been, but it’s still going to be a pain. Thanks Eolas! (who’s up for TPing their corporate offices?)

Macromedia has been very responsive to this issue, and should have utilities to help us transition smoothly available soon (good job MM!!). It will soon be our turn, as developers, to ensure the transition continues smoothly. It should be our collective goal to make sure that when the first browsers with this change hit consumers in early 2004, users are met with a minimum number of prompts – we really don’t need to give people a new reason to hate/disable Flash.

[EDIT:] Does anyone know the answer to this very important question:

Does anyone know if the new IE differentiates between disabling Active Content prompts, and disabling ALL Active Content? This one issue will have a huge impact on our industry.

by Grant Skinner

[code] GForm: Form class extended

I recently completed a tutorial for Ultrashock on creating an MVC based application using forms and screens. Writing it was more of a struggle than I expected, in part due to the lack of documentation on the subject at the time (it has improved since), but also because the current Form implementation lacks a couple of elements that I would consider requisite for developing a clean application:

  1. The Form class does not include a collection of child forms. This means that you can only reference child forms by a largely arbitrary index number, not by name, unless you declare each child form manually in your class.
  2. Because the class initializes before the UI components it contains and its child forms, it is very difficult to write logic that sets up and populates interface elements initially, or sets listeners on child forms.

Continue reading →

by Grant Skinner

GDispatcher bug fixed.

I’ve uploaded a new version of GDispatcher that fixes a small error in the code that was causing a compiler error.

You can download the new version here (1kb).

There should be a beta 2 release in the next day or so, as I mull through some major compatibility issues with the highly discombobulated UIEventDispatcher class. Some days I wonder if Command HQ doesn’t go out of its way to make things overly difficult for us guys in the trenches – the v2 component framework seems to be irrefutable proof of it

by Grant Skinner

[code] GDispatcher: Event swiss army knife.

A few posts back, I mentioned that I was planning to extend the EventDispatcher class to add some features that I wanted. I quickly realized that to satisfy my needs, I would need to do a full re-write, and GDispatcher was born. Being the generous fellow that I am ;), I thought I’d share it with the community – read through this post to download it.

GDispatcher is a new event dispatching class for ActionScript 2.0. It fully implements the EventDispatcher interface, allowing it to be interchanged easily (yay polymorphism!). Beyond the basic functionality found in EventDispatcher (described here), it also supports these new features:

  • Listeners can subscribe to all events from a dispatcher
  • Listeners can specify a function to handle specific events, or all events (within the scope of the listener)
  • Can check if a listener is already subscribed to an event
  • Can remove all listeners for a specific event or for all events

Continue reading →

by Grant Skinner

Event dispatcher, the next morning

Ok, I have to post a bit of a retraction. While EventDispatcher is still a big improvement over previous event models, it’s not quite as cool as I thought it was at 3am last night. Nothing ever looks quite as hot the morning after, does it?

The ability to subscribe functions or methods to events is made vastly less useful than I excitedly thought last night by the fact that the function will, of course, be executed within the scope of the object dispatching the event (duh). This means that really, this approach is only about as useful as a callback event handler (the functionality is virtually identical) – its occasionally handy for quick’n’dirty prototyping, but usually not good form.

Ahh… the murky clarity of 3am experimentation. Oh well, stay tuned, I hope to build out an extended version of the eventDispatcher that includes some nifty new tricks.