Category: Flash

Docs say it doesn’t, but it does. Here’s my fav; a borderless one!!!

– drag a ScrollPane on stage
– select it and delete it (so it’s in your library)
– draw something big
– select it
– make it a movie clip
– delete it from the stage
– give it a linkage name of “test”
– make a new layer
– put this code on it

attachMovie("ScrollPane", "mc", 0);
mc.setSize(100, 100);
mc.contentPath = "test";

function onKeyDown()
{
        switch(Key.getCode()){
                case Key.LEFT:
                mc.setStyle("borderStyle", "none");
                break;
                
                case Key.UP:
                mc.setStyle("borderStyle", "inset");
                break;
                
                case Key.RIGHT:
                mc.setStyle("borderStyle", "outset");
                break;
                
                case Key.DOWN:
                mc.setStyle("borderStyle", "solid");
                
                break;
        }
}

Key.addListener(this);

– test movie
– pressing “left” arrow key is my favorite; borderless

Funny thing, if you scroll your content to the middle, and then keep pressing down and left, down and left, etc., the content will move slightly. A bug, but no one would really care.

One of these days I’ll make a tutorial on skinning as well as do that “uber size method” article, but till then, here are my notes I collect throughout my travels in the Flash MX 2004 framework.

Intro

Skin stuff has deep ties with UIObject. UIObject is the base component class. UIComponent helps, but UIObject is the one you should pay attention to. There are some properties n’ methods setup in him in preparation for some of the skin classes, interestingly enough. With frameworks, I’m starting to feel because your building something to help, it’s ok to cross pollenate knowledge of other classes. Everyone has a job, but that doesn’t necessarely mean each person shouldn’t have knowledge, even if a little bit, about another’s. That violates OOP, but who cares, this stuff works.

Da Skizzy

Ok, first off, all of the good stuff is in mx.skins. The main dude, SkinElement, is what you input into a skin. So, you make a movie clip, put your shiot in it, and then input mx.skins.SkinElement into the AS2 class for that symbol and your good.

There are a few other support classes in there to help with foundations, such as borders. The RectBorder is used for outlines n’ such. CustomBorder, however, operates like a window titlebar; it has 3 pieces; a left, right, and a stretchable middle. I personally haven’t found using this class directly to work. Skins, at least in CustomBorder’s case, do not have an initial width and height property, thus rendering them useless. They do, but those properties don’t have values. The size method will get called, but it won’t have any values associated with them, thereofore, it’ll fail to position the middle and right correctly. I looked at mx.controls.scrollClasses.Thumb or whatever, as he seems to use CustomBorder, but didn’t see anything that helped.

So barring that mofo, let’s get to the properties that, like SkinElement, I actually know how to get to work.

Mad Props

Typically, if you have a skin for, say, your background, you’d define a private variable equal to the linkageID name. So, for a window component you’d do:

private var backgroundSkin:String = "WindowBackground";

Where that is the linkageID of the movie clip that houses the WindowBackground. When you attach him, you can then call setSize on him, but he doesn’t have all the functions that UIObject has. SkinElement is a lot like UIObject, but is greatly simplified, thus reducing memory costs.

Here’s where things get fuzzy for me, but let me define some more properties first before I explain how to use that private variable.

One more note about him; since he’s defined with an initial value, he’s on the prototype of the class. Therefore, all instances will have that value by default. If you change that value for that class, only he will have the modified property. If you change the prototype value directly, all instances thus forth will have the new property’s value. This, too, helps in memory since initially, the string is only stored in one place. So, if you want one component to have a different skin, you can just set is backgroundSkin variable to something else via the initObject when creating.

refNames

This, like all of the mix-in style classes, is an array of strings. This array houses the linkageID names of all the skin elements you’ll be using. It may seem redundant because you just set all of those strings to variables, but I believe this is used for look up for the setSkin method.

tagMap

Here’s mx.controls.SimpleButton’s implementation (I think it’s him):

An object where property names are skin names, and numbers are
skins’s ID; a number. They are used for depth, as well as the getSkinIDName method, which the tag is passed in and used as an an array index, from idNames, to
return the linkageID name to use in createEmptyObject, which is a simple wrapper for createClassObject creating a UIObject instance.

In my words, it’s just a simple way to house both the skin’s ID # as well as it’s linkageID name all in one object. Further redundancy, but I’m sure there’s a reason.

Use dat Shiot
The end result is, instead of using createObject, createClassObject, or attachMovie to make your skins, you do setSkin. It requires the id, linkageName, and initObject if you want one. To me, you’d do:

setSkin(tagMap.backgroundSkin, backgroundSkin);

And I believe the end result will be that it will respond to style changes as well as other setSize events. The registration with the skin registry variables seems kind of dumb. The SkinElement register element is just a wrapper for Object.registerClass… but I wouldn’t be using that class if it wasn’t a skin… Also, I think the skinRegistry global is just to check it’s actually a registered skin. You can do the same thing with attachMovie, but it’s cleaner and better managed this way… at least, that’s the feeling I get the more I dig. No, I have no idea all of what’s going on, but this is how every other component does it, and after finding out why createLabel was cooler than createTextField, I’m using history as the best teacher.

…and the research continues…

Dude, figured out why createLabel makes your text field invisible. Check this comment in the mx.controls.SimpleButton class for the createChildren method (called by extendee’s of UIObject):

create children objects. Components implement this method to create the subobjects in the component. Recommended way is to make text objects invisible and make them visible when the draw() method is called to avoid flicker on the screen.

Well blow me down… is that even possible? Anyway, makes sense now. I like how ever time I learn something, all of my current components are now wrong, hehe. Maybe I should just remain ignorant, then my code would R0cK!!!

If your component inherits from UIObject/UIComponent (one of the 2), and you utilize the createLabel command, the text field can then respond to style changes (CSS based).

Since I use createTextField all over the place in my components, createLabel is nice. Basically, it’s the same as createTextField, but adds all the style info and power it needs to respond to setStyle changes (globally, class, or instance based). It’s kind of weird in that it immediately turns your text field’s _visible property to false, but other than that, it does all the CSS integration for you.

One problem I just found, though, is if you stuff it full of HTML text after you create it (I believe a frame after), the HTML will overwrite the formatting since with html textfields you can format with HTML formatting (whoa…).

Not sure the “correct” way to be formatting my HTML, I guess via getStyle, and dupe a stylesheet, and then apply it, but in the interim, I just immediately call setStyle after I set it’s htmlText property, and the formatting (font) is good again.