Category: Flash

I just had to blog this insanity. It’s about a week old, so time for some reflection.

Intro

It started off with our Human Factor’s guy going, “Can we edit this text’s font at a later date?”. I’m like, “Sure.” knowing that I can wire my component’s properties of text to the global styles that the new framework uses. I needed an excuse to learn them, and since I’ve got skinning mostly down, I figured, what the heck, how hard can it be?

I then ran into a snag; my component (SWC) didn’t have it’s text change to bold when I did a setStyle. I received no compile errors, and all other functions of my component worked. Oddly, when I dragged a Button (mx.controls.Button) component onto the stage and then did a test movie again, both it and my component had it’s text turn bold when I did a setStyle. “Uh… hey thanks Button. Can I have what you have?”

Digging in the SWC of Button, he had a crud load more classes than I did. So, I started digging into the base classes to see who instantiates setStyle. Well… no one. It’s defined as a function in UIObject.as, but it’s merely a dim/definition of a variable. Pretty goob-a-rific with the comment, too.

Style Class Found – The Plot Thickens

Turns out, CSSSetStyle.as (mx.styles.CSSSetStyle) is the homeskillet responsible for the method of style-powah. But, no one instantiates him. Frustrated, I called in the artillery. I had a co-worker use Visual Studio .NET to find in files (since SciteFlash wasn’t installed), and turns out some obscure class, UIComponentExtensions.as is the ONLY ONE who instantiates it. And get this, the method it calls, enableRunTimeCSS, is a static function that does Jack and shiot. It’s merely there, I think, to ensure CSSSetStyle actually gets exported with the framework upon making an SWC. :: takes a hit from the bong :: Ooook… makes sense.

The Horrible Climax

Next, the search was on for who instantiates UIComponentExtensions.as (mx.core.ext.UIComponentExtensions). I think it was only found in the comments of some class. I was flabbergasted. If no class instantiates it, how in the hell can it exist? I just assumed it was called via some function that only your mother can call, similiar to how the CSSSetStyle worked… but that wasn’t the case.

At the end of my rope, I ventured a gander over to Flashcoders, and said a prayer my email wouldn’t get lost in the flood, and sent her off. I actually got an answer, and quickly too.

The Aftermath

At that point, Peter Hall’s response confirmed my anger as of this morning. What crackhead thought it was a good idea to revert to Flash MX tactics to create a coding framework should have his/her head examined. It’s already been established in Flash 5 that anything beyond a stop on the timeline is an unacceptable coding practice, and in MX, you merely dropped your assets to fit into the #initclip order sequence.

Now, however, that’s taken care of for us. That is NOT an excuse, though, to utilize the timeline as a constructor call, thus instantiating an entire style setting system for components. Frankly, it’s bullshit.

What’s worse is I don’t think it can be changed/modified without affecting backwards compatibility. The workaround is fine; I can definately live with dropping a component or 2 of a base class inside my SWC, no worries there. The methodology, however, in what I am doing is archaic.

Techniques like this deplete my prozac supply in which I use to placate frustrated Java programmers. Help.

To those of you that think memory management is old hat, more power to you. However, there are those of us who have never had the opportunity to worry about such things in the past. Who knows what is really happening behind the scenes, but I was trying to load 26 XML files. The process goes:

– get xml filename
– attach to existing LoadVars variable (not local)
– do a POST to PHP script
– PHP script uses the passed in filename, loads the gZipped XML file, and returns to the LoadVars callback as a variable “theXML”
– LoadVars’ callback then throws that string to the xml object via owner.my_xml.parseXML(theXML)

Now, each XML file, around 300k, was making the memory jump 20 megs every load. So, the 9th load would usually crash Flash. I thought it was the XML object, but turns out, it is the LoadVars object. Even though his “theXML” variable is reset each time, the string data in memory isn’t.

To solve it, I added a “delete this.theXML;” after I passed the string data to the XML object to parse. This doesn’t entirely solve the problem, though. Even though I can see the RAM drop about 20 megs, she still climbs to a whopping 80megs when finished. I really don’t think my nested array/objects are what is causing the significant increase, and there aren’t many components on stage nor in use. At any rate, at least it doesn’t crash now!

Chafic wrote this phat article (that he shoulda let me tech edit) on Ultrashock. He took a monumental task in writing it, so I congratulate him.

I wanted to add a few things that the V2 framework doesn’t take into account as far as Flash goes.

Authortime Components

This is the bane of the mixed group of developers we have in the Flash community and on the help lists. Some of us use authortime components, others dynamic, and some both. I try to attach everything dynamically myself, but for those gigantor forms, or intricate layout times, it?s just quicker & easier to drag and drop. The difference is, if a component is an authortime component, it is initialized (methods, not properties) a frame afterwards. The exclusion to this rule is if you drop it on _root, but even then, if your SWF is then loaded into a movie clip, you have the same problem again.

The way I typically solve this is just to implement an onLoad in my class. Thus:

public function init(Void):Void
{
        super.init();
        
        setSize(320, 240); // set a default width and height
}

public function onLoad(Void):Void
{
        my_pb.addEventListener(?click?, this);
        my_pb.label = ?Sup?;
}

Same holds true for Central components. I think Flex handles this transparently. Now, technically, one could argue you should be using createChildren to attach everything? but to me, that is not realistic to do every time. It violates OOP purism, but I?ve got deadlines to meet, and I know some of you do, too.

createClassObject/createObject prefix

This is more of an opinion because I haven?t looked at the FLASM output, but I consider it a best practice to call removeMovieClip before ever creating anything (createEmptyMovieClip/attachMovie/createClassObject, etc.). It may just so happen that the bytecode is the same for creating a movie clip in the same depth as another one (even if the same movie clip), thus deleting whatever is there, but there is one distinct case I can argue: corrupted movie clips. Sometimes, when loadMovie fails on loading JPEGS (not sure about SWFs), it?ll corrupt the movie clip. This is mega lame if you authortime dropped it because now your foobarred? unless you swap it to a positive depth and then removeMovieClip on it which is hackish… but necessarey I guess in the case of deadPreivew (talk about this later). Thus, removing a movie clip before attaching it, to me, should have been added to the createObject method (since createClassObject calls it anyway). I haven?t, however, had this problem with text fields, so I don?t call removeTextField before creating them.

Finally, and I don?t really know about a fix for this, sometimes onEnterFrame?s that are dynamically attached I believe hang around via the activation object. So, even if you delete the onEnterFrame before calling removeMovieClip, and even get a true returned value from the delete call, your onEnterFrame will still get called. I don?t really know how to fix that, even if it could, but it really just confirms you should be using doLater vs. rolling your own onEnterFrames, unless of course they are on process only movie clips (mc?s created specifically and only to generate that event for your use).

Width & Height, deadPreview, and LivePreview

You?ll notice above I called setSize in my init. I did this because, by default, __width and __height are based on _width and _height. Now, if your creating the ideal component, there really isn?t anything to base a valid _width and _height value off of, is there? Well maybe? depends on how you make things.

Back in MX, width and height were getter/setters for width and height. That is, they were NOT pointers to _width and _height values, which to me, is a failure, again, for the V2 framework to make allowances (yes, they are allowances, that?s why frameworks rock) for Flash. For example, an image is 1000×1000, however, your masking it off at 320×240. Know what width reports? 1000. Stupid. Thus, that?s why MX rocked, because no matter what you did via setSize, it always correctly reported the ?true? or ?visual? width and height; if for some odd reason you needed the true _width, you can just access it. That?s why in MX it was integral to default to something because the base class, FUIComponent, did not.

Typically, you?d put your components your using on frame 2, with a stop action on frame 1, thus having a nicely packaged component, reading for SWC exportation. However, this causes 2 problems. First, there is nothing on frame 1, therefore, width and height won?t be jack (well? 0, 0) because there is no physical element on frame 1 for it to get bearings on what _width and _height will be. Second, because there is nothing on frame 1 (aside from a stop action), your LivePreview for your component won?t work. LivePreview?s, since MX, have needed SOMETHING on their stage (separate SWF in MX, frame 1 in 2004) so they can have a rect in which to draw in. Thus, in MX, deadPreview was born. If you turned off LivePreview in MX, you?d see this sketchy, or non-live component. Typically this was just the pieces of the component put together in a semblance of what the component would look like? or what you saw when you did an edit in place on components. This was done for those who turned LivePreview off in the IDE. Additionally, an automatic unloadMovie was called on deadPreview (you typically named your movie clip that) so it was removed when your component was run. However the V2 framework has removed this? as mistake in my eyes.

Because of deadPreview’s new role in as the frame 1 rect creator for SWC LivePreviews, it now has 2 roles (first here, 2nd below this paragraph). I?ll typically still use deadPreview, and call swapDepths(0), and then removeMovieClip (since removeMovieClip doesn?t work on negative depth movie clips a.k.a. authortime movie clips). I have my own base class which uses Grant Skinner?s GDispatcher, and extends UIComponent, so I put the deadPreview stuff in there since everyone uses it. Still, I shouldn?t have to, but that?s a case where inheritance rox da hizz-ouse!

Finally, a deadPreview gives your component a _width and _height that UIObject can work with, thus negating the need to give it a default width and height by calling setSize in your init. I still do so anyway, though.

Conclusion

I love Chafic?s article as I learned a lot (and now all of my classes need to be rewritten) and I love the V2 framework as well. It?s a lot easier to make my modifications without it breaking via another Flash IDE update, or some other addition since it?s nicely encapsulated. I?m a guy that likes to use frameworks, not create them, so it saves me a ton of time. Hopefully the above will help you navigate the Flash nuances that the V2 doesn?t solve.

We have this Human Factors guy working here. Name’s Shayne. He did this wireframe for some of the Pod’s I’m building. So, we get together to discuss my current work and to ensure I’m hitting his vision on how things are designed. He’s not technically doing design here, but he pretty much gave my team the Illustrator design to use, both for layout and look and feel as well as the wireframes beforehand.

We started dicussing the layout of the pods, with their use of the design elements and text. Within an hour, I had been schooled on layout, use of fonts, and textual elements. I had pretty much gotten a college layout class, in less than 30 minutes, for free.

Bad news is all of my component’s size functions are now pretty much needing to be rewritten. The good news, however, is I now know how to do them 90% right. He says I won’t get all of my margin/positioning rules right the first time, nor have I got all of this figured out yet. I have 2 pages of his notes with which to use as reference; some on the back of wireframes, the other on a graph paper I ganked from my manager. Good stuff. Makes layout using coding harder, but in the long run, a lot better…looking.