Blog

  • Short Stint in Skinning Flash MX 2004 Components

    So, helping a friend today with figuring out how to skin the Window’s title bar and the ScrollPane’s Scrollbars.

    The first took some working, but originally, she looks like this:

    And using this code:

    _global.styles.Window.setStyle("borderStyle", "outset");
    mx.managers.PopUpManager.createPopUp(_root,
    mx.containers.Window,
       true,
       {skinTitleBackground: "test",
       skinCloseUp: "bu",
       closeButton: true});
    

    She looks like this:

    Notice in the above code, I pass in the skin variables in the initialization object. There is another to do this ahead of time as I’ll show you below. The strings are the linkageID’s of the movie clip’s I’ve created. The skin creation is really simple:

    – create a movie clip
    – put art in it
    – right click on the symbol in the library
    – give it a linkageID name
    – make sure it’s exporting in frame 1 (otherwise, you’ll have to put it manually on stage somewhere before you use it)
    – in the AS 2.0 Class field, type “mx.skins.SkinElement” (this makes the movie clip size with the component)

    Done!

    However, for components within components, you don’t have control of their constructors, nor access to them usually. Now, there may be another way to do this, but accessing the default skin properties is easy. In the ScrollPane’s case, here’s how he normally looks.

    However, if I want to skin the Scrollbar, I merely set the prototype values to something different than the default before creating the ScrollPane:

    mx.controls.scrollClasses.ScrollBar.prototype.scrollTrackName = "scrollbar_track_green_mc";
    mx.controls.scrollClasses.ScrollBar.prototype.upArrowUpName = "scrollbar_arrow_mc";
    mx.controls.scrollClasses.ScrollBar.prototype.downArrowUpName = "scrollbar_arrow2_mc";
    mx.controls.scrollClasses.ScrollBar.prototype.thumbTopName = "thumbTop";
    mx.controls.scrollClasses.ScrollBar.prototype.thumbMiddleName = "thumbMiddle";
    mx.controls.scrollClasses.ScrollBar.prototype.thumbBottomName = "thumbBottom";
    
    attachMovie("ScrollPane", "mc", 0);
    mc.setSize(320, 240);
    mc.contentPath = "test1.jpg";
    

    He now looks like this:

    Granted, now that I’ve set the prototype, all Scrollbars will use the same skins, so this method does not allow for individual Scrollbar skinning, but I’m sure there is a way somehow; I’m still learning.

    Hope this helps!

  • Generate Flex Component Code via Flash

    If this script was developed further, one could generate Flex component code by dragging Flash components to the stage for those more used to visually laying out forms vs. using the tag based approach. Anyway, works for Buttons and Labels. The Accordion started to get deep, so I’m pulling the plug, but thought it was a pretty interesting concept nonetheless. I wonder if Brady will work on a similiar concept using Dreamweaver’s JSFL?

    Generate Flex Component Code – JSFL

  • I got my Flex CD

    I am so excited.

    :: installs ::

    I’ve installed it, and ran though the samples that it comes with. Few things I think are cool, and two things I don’t.

    I’ll say what I don’t like first, just to get it out of the way. I don’t like the updated components; I like the Flash MX 2004 Halo ones better. Additionally, something puzzling was going on in a few of the apps, I believe when using the Accordion component. It appeared that it was causing a post-back (page refresh) everytime you loaded a new pane. I know that, without fscommand, that is one thing that killed a part of my past project at my current company as it interferes with javascript running on the page as well as elements loading such as form controls. One may argue that you should be doing the entire app in Flex anyway, but I still don’t like the looks of how that works. It really should just do a load movie or something… I didn’t look at the innards, so maybe it’s actually calling the mxml file, or can be changed easily.

    Now, the good stuff.

    First off, their layout managers are great. I know iteration::two has already talked about them, but to me, they solve I’d say about 40% of my total development time. Because I’m anti-authortime man, I spend a lot of my time writing my size function which lays everything out. A lot of times, it’s only called once in my entire app’s lifecycle; total waste of time. I gotta say, mad score for that.

    Secondly, dig their ViewState component. A lot like the TabView, only …well, simpler and not as in your face.

    I really dig how easily my existing components I create can be incorporated into a Flex app; it’s pretty insane that it’s that easy.

    Finally, the coolest thing was how easy it is to add tooltips… omg, the only thing just as easy is Central’s way of doing it.

    Anyway, they have some neat samples to look at, and a few scattered goodies throughout the install directories. It’s interesting to see they packaged the framework into an SWC + they have a debug one seperate. Clever!

    One thing, though… there is no way my box meets the server requirements. I can hear my comp click away when I was hitting some of the more adavanced MXML files. All in all, I can definately see a niche in creating components again. Very cool prog, and it’s only been 1 hour with the CD!

    *** Edit

    Oh yeah, another thing that blew me away was the JSP integration. I’ve never seen JSP up close, but it looked just like PHP. The fact that you can create Flash apps that way suddenly hits home the whole “enterprise developer” thang. I know soooo many people that code like that. I KNOW there has to be a PHP version lurking in someone’s mind because that looks… geez, just like PHP. Anyway, very frikin’ cool the integration with HTML can be so tight.

  • Failed Component Preview Command

    Another one of my cast offs from the lab. This one started from a change in development. I’ve started creating more SWC’s within SWC’s rather than a bunch of Shared Libraries; this allows me to compile faster in the later stages of a project. The issue is, unit testing is severly impeeded early in the game, because I’ll usually have one file with all the classes in it vs. a FLA for each class. Therefore, my compile times get worse and worse as time goes on. What I’ve been doing to solve it is make a new FLA, and create a movie clip, fill in the class info, and test that. However, this gets tedious to do over time. Saving a FLA is an option… but I don’t like various versions of my MC’s hanging around since I massage my package (gross) structure early in the game.

    So, I figured, why not just creat a quick jsfl script to make a new FLA, create a movie clip, and test it?

    …well, it worked in theory…

    I quickly found that this solution was only good for classes that didn’t require sub-classes. I always start small, but these things get so big (gross). So, I started adding in logic for defining sub-classes if applicable. However, even though I found some good XUL documetation on the web + using examples from a few extensions I have installed, none of them used code… and the ones that did were not XUL, but instead Flash Panels (a SWF running in a window inside of Flash). I found that a lot of XUL can be scripted with JavaScript, in our case, JSFL. …however, I quickly found the scope is in it’s own memory space. It’s weird; it has references to the app (app/App/fl/flash), and even has references to it’s own XULMI return object, plus any others created, as well as theTool (??? gross???). There was no way I could hack to get a reference back to the original jsfl calling script (the one that called the XUL dialogue). The bottom line was, I could put JSFL code in the button’s oncommand attribute, but it wouldn’t populate the listbox I made, even though it traced out as a valid property.

    <button label="Add" oncommand="fl.trace(‘sup’);" />

    “Fuggit”, I said as I made a Flash Panel instead. I then ran into another problem; base components. You cannot simply include their classes; you need the base SWF, or in this case, the base SWC file. So, I proceeded to make an interface that allowed you to add those too. A lot of my components use the drawing API, so AS alone is good for the above.

    However, my final brick, and fatal wall was fl.componentsPanel.addItemToDocument. That damn function only attaches components to the FLA where the JSFL script was called from, even if you set the new document to focus. I tried everything I could think of (focusing more than once, doing weird things to the document object, saving it, closing it, focusing it 5 times), all to no avail. This test scripts shows an example. Create a FLA, run it twice… it’s always one doc behind…

    var doc = fl.createDocument("timeline");
    fl.setActiveWindow(doc);
    fl.componentsPanel.addItemToDocument({x: 0, y: 0}, "UI Components", "Button");

    I tried my damndest to figure out a hack, and then just surrendered in defeat. Did I mention I hate losing? Just so we’re clear.

    Hopefully, some of you can learn some JSFL/XUL/Flash from this failed attempt at becoming more productive.

    File structure is explained in the zip.

    Failed Preview Component – ZIP