Category: Flash

The MediaDisplay component has an onUnload event to ensure the FLV or MP3 it’s playing is closed before the component goes away. If you, however, attempt to create a movie clip/component with the same name in the same frame (or maybe it’s depth), it won’t work. You must wait a frame because the onUnload keeps a reference to the clip and stays around until the next frame. This caused havoc in a speech preso I was doing for school. I implemented a quick and dirty doLater to ensure I had no issues.

function doLater(obj, meth:Function):Void
{
        if(post_mc == null)
        {
                createEmptyMovieClip("post_mc", getNextHighestDepth());
        }
        var d:Number = post_mc.getNextHighestDepth();
        var ref_mc:MovieClip = post_mc.createEmptyMovieClip("d" + d, d);
        ref_mc.obj = obj;
        ref_mc.meth = meth;
        ref_mc.onEnterFrame = function()
        {
                trace("ref_mc calling");
                this.meth.call(this.obj);
                this.removeMovieClip();
        };
}

Dude, Indeo 5 blows when importing videos. I kept creating small import clips in the import wizard, but the video was waaaay off sync… if at all. It didn’t even import all of the clips.

I’m now attempting to learn the Media Display component at moch-10 billion since addQuePoint seems the way to go at this point with a honkin’ 9meg, 12 minute external FLV. It’s going to be weird animating movie clips, and then attaching them via an event listener vs. the old skool way to merely animating things in the timeline.

On a brighter note, the weather here rocks, and I’m reminded of it after just getting back a roll of film developed and looking through the pictures. Her majesty had photographed the ice storm and man… do I NOT miss that cold weather crud; the warm, sunny weather here at Bondi Beach rocks! It’s been a battle getting me out doors, though, as I have so much stuff to code & homework to do before the conference. Not to mention her majesty’s on reckon finding a hotel for Tuesday night… hope that goes well.

Saw Aral on the way here out in the middle of the Pacific. Hard to spot 40,000 feet up, but man, he look tired… poor bloke.

As the tasks, goals, and due dates pile up, I wonder what the heck I was thinking in even believing I could accomplish all of the things set before me. I fear boredom worse than death, and this has formed a masochistic behavior in setting unattainable goals for myself. I don’t necessarely get all that frustrated not attaining them all, because I’d much rather be swamped then wondering what there was to do.

A class I thought I’d share is the ViewStack. I implemented my own version in Flash. The ViewStack is one of the hot container classes Flex has. It basically creates a bunch of components in itself, and lets you toggle their visibility. What this acheives is an extremely easy way to create wizards and other light weight, multi-step processes. Mine doesn’t compete with Flex’; there is a lot more that the Flex version has both implemented in it, and underneath from the inheritance tree, but mine serviced fine for lightweight component toggling. I built mine from scratch and didn’t really compare to the actual AS file, so I’m sure mine pales in comparison, but hopefully this’ll give you a better appreciation of what Flex has to offer, and how implementing this, already built in Flex, stuff is kind of… uncool to do in Flash. I’d rather just have an SWC that worked, and legally. It’ll be challenging to see how I handle transitions…

Anyway, to get it to work, you’ll need 1 additional method in your mx.core.View class:

function getChildIndex(child:UIObject):Number
{
        var i:Number = numChildren;
        while(i--)
        {
                if(getChildAt(i) == child)
                {
                        return i;
                }
        }
        return null;
}

Haven’t hardcore tested the above function, and it’s different than Flex’ implementation (which I’m sure has been QA tested), so use at your own risk.

Then, the ViewStack class:

/*
class: ViewStack
by Jesse Warden
jesse@jessewarden.com

The ViewStack implementation I've done
is a gross simplification on the Flex one.
Basically, it just takes controls,
and controls their visibility.

If you want to buy me Flex, send me an email!

*/

import mx.core.View;
import mx.core.UIObject;

class ViewStack extends View
{
        // group: UIComponent variables
        static var symbolName:String = "ViewStack";
        static var symbolOwner:Object = ViewStack;
        public var className:String = "ViewStack";
        
        // group: private
        private var _selectedChild:UIObject;
        private var _selectedIndex:Number;
        
        // group: getter/settters
        // ---------------------------------------------------------------------------
        public function get selectedChild():UIObject
        {
                return getChildAt(selectedIndex);
        }
        
        // ---------------------------------------------------------------------------
        public function set selectedChild(obj:UIObject):Void
        {
                _selectedIndex = getChildIndex(obj);
                refresh();
        }
        
        // ---------------------------------------------------------------------------
        public function get selectedIndex():Number
        {
                return _selectedIndex;
        }
        
        // ---------------------------------------------------------------------------
        public function set selectedIndex(val:Number):Void
        {
                _selectedIndex = val;
                _selectedChild = selectedChild;
                refresh();
        }
        
        // group: methods
        // ---------------------------------------------------------------------------
        function ViewStack()
        {
        }
        
        // ---------------------------------------------------------------------------
        public function init():Void
        {
                super.init();
                
                _selectedIndex = 0;
        }
        
        // ---------------------------------------------------------------------------
        private function doLayout():Void
        {
                super.doLayout();
                refresh();
        }
        
        // ---------------------------------------------------------------------------
        private function addLayoutObject(obj:Object):Void
        {
                refresh();
        }
        
        // ---------------------------------------------------------------------------
        private function refresh():Void
        {
                var i:Number = numChildren;
                while(i--)
                {
                        var child = getChildAt(i);
                        child.setVisible(false);
                }
                
                var selChild = getChildAt(selectedIndex);
                selChild.setVisible(true);
        }
}

Finally, example usage (drag Button and TextArea components into your Library, then put your ViewStack MovieClip on stage, and name it “mc”):

mc.createChild(mx.controls.Button, "cal1");
mc.createChild(mx.controls.TextArea, "assign1");

function onKeyDown()
{
        switch(Key.getCode())
        {
                case Key.LEFT:
                mc.selectedChild = mc.cal1;
                break;
                
                case Key.RIGHT:
                mc.selectedChild = mc.assign1;
                break;
                
                case Key.UP:
                mc.selectedIndex = 0;
                break;
                
                case Key.DOWN:
                mc.selectedIndex = 1;
                break;
        }
}

Key.addListener(this);

It is not as efficient as Flex b/c it doesn’t implement a creationPolicy, doesn’t resize to the content, and a ton of other things… but the concept is cool, so far works in a prototype.

The weird comments are for NaturalDocs. I got it to work, and really dig how easy it is to add documentation to my code without crazy comments. Once I got a bat file setup, it was really easy to recompile my documentation after a code change… and NaturalDocs is smart enough only to recompile the changed class. Good stuff!

Old class (circa September 03, 2003, 2:49:24 AM… late night Nigel, hehe, or is that Cali time since I’m 3 hours ahead?), but I only now gained an appreciation for it. I was looking into a common pattern Flex uses in creating and deleting children (movieclips/components). Since a lot of the components in Flex are containers, they inherit from View up their inheritance tree, and therefore have the createChild, destroyChild methods. The createChild method is nicer (to me) than the createClassObject for a few reasons:
– shorter to type
– takes 3 parameters; the class name | the instance name | an init object, createClassObject takes 4; the 3rd being the depth

Ex, UIComponent:

createClassComponent(Label, "my_lbl", getNextHighestDepth());

vs. View:

createChild(Label, "my_lbl");

…ahh, removing un-necessarey implementation details; OOP rulez.

Additionally, View, the Flash version, already has the boundingBox_mc property defined, and already has the code to remove it in the constructor so you don’t have to repeatedly define this in your classes the extend UIComponent.

It also already sets up tabbing for children within your component by running the 2 methods I always end up repeatedly typing into my own classes:

tabChildren = true;
tabEnabled = false;

It also automatically implements a rect border; I believe this is used for borderStyles; you can see a good example of this in the Loader component, the comp used to load external content.

yourLoader.setStyle("borderStyle", "inset");

Your draw and size functions are replaced with doLayout, which you have to call super on. Additionally, for one-time layout deals, you can implement initLayout and call super on it; it’s good for stuff you’d typically put in your createChildren (have to call super in this one too), but didn’t necessarely have to do with creating children clips.

You end up with a really nice class file structure going that is more lean than the UIComponent version.

View
– constructor // good practice
– createChildren
– doLayout
+ init & initLayout optional

vs.

UIComponent
– constructor // good practice
– init (calling super)
– createChildren
– draw (for your backgroundRect mostly)
– size
+ boundingBox_mc in your properties

I typically run my getter/setters to set themselves in the initLayout, but you could do it in the createChildren if you really wanted.

…however, View appears somewhat unfinished in the Flash version (and both are missing the implementation of convertToUIObject, which converts externally loaded content via createChild to a UIObject… well, it appears that’s what it was eventually supposed to do).

Update on convertToUIObject from off-blog email:

…convertToUIObject is actually implemented in mx.core.ExternalContent. I guess it would be considered a mixin without a target. It’s a little weird.

Here’s the part of ExternalContent.as that references View:

static function classConstruct():Boolean
{
	var v = View.prototype;
	var p = ExternalContent.prototype;
	v.loadExternal = p.loadExternal;
	v.prepareToLoadMovie = p.prepareToLoadMovie;
	v.waitForUnload = p.waitForUnload;
	v.checkLoadProgress = p.checkLoadProgress;
	v.contentLoaded = p.contentLoaded;
	v.convertToUIObject = p.convertToUIObject;
	return true;
}
static var classConstructed:Boolean = classConstruct();

View loads mx.core.ExternalContent and ensures that it’s actually there (i.e. not just loaded for type checking) by including this code in the class definition:

// this never gets called, it just makes sure the external content module gets loaded
static function extension()
{
	mx.core.ExternalContent.enableExternalContent();
}

Now, that’s ok for the Flex version… but you’ll start to realize that the Flash version is missing some important children management functions. UIComponent has destroyObject, which takes care of removing the movieclip/child component, authortime or not, and deletes the variable. It’s a bit unweidly because it takes a string, I guess because they assume your gonna keep a list of skin clips like some of the components do… not me.

Case in point, destroyChildAt; its expecting a number which represents which child to remove. Do you know what child is 3? Do you know what # your submit_pb is? I don’t either, nor do I wanna manage that crap… the whole point of a helpful base class is to be… well, helpful.

Looking in the Flex version, it implements some of the necessarey methods to prevent you from having to manage this information yourself; namely:
– getChildAt(index:Number)
– getChildIndex(child:UIObject)
– destroyChild(child:UIObject)

Implementing these methods yourself is trivial, and the Flex implementations of them are not to my liking (I didn’t like the way Flex wrote the innards of those functiosn), which is a good thing since my implementations have no relations… except the end result; managing my children for me.

It has a few other useful methods too, but I don’t really need those; adding the above, including destroyAllChildren via my own, quick implementations, makes View a superior class to use for visual components that implement heavy use of Composition; a lot of sub-movieclips/components used in a wrapper class, AND with less code.

mx.core.View is not for everyone… hell, mx.controls.Label extends UIObject! I am definately digging it though for a lot of my fixed-sized forms I’m building in Flash (miss you Flex!); leaner code, and less I have worry about writing, and instead focus my time on writing application specific code.

Check out View today!