Page 1 of 3 Most of us have at least one mentor, even if it's someone we haven't met in person. In fact, if you're anything like me, you have a different mentor for each field that interests you. Someone who inspires you to keep practicing the piano, to get creatively crazy in the kitchen, to learn yet another unicycle trick, and to keep strengthening your grasp on Flash (or Photoshop, or Dreamweaver ... you get the idea).
When it comes to Flash, one of my mentors has helped me significantly with troubleshooting — with making things work when, against all expectation, they simply don't work. In this series, I'd like to explore a single theme — troubleshooting — from a variety of angles, sharing with you what my mentor has shared with me. Along the way, we'll turn up a few quirks involved in working with Flash, but more importantly, we'll review how to approach arriving at useful workarounds, regardless what the issue is.
Here in Part 1, we'll start with a lowly movie clip symbol.
I can easily name half a dozen Flash gurus who have encouraged me to pursue expertise in this particular application, but there's one programmer in particular — a personal friend of mine who calls himself Uncle Chutney — that doesn't know the first thing about Flash. What he does know is how to program, a general skill that has guided me through forays into Java, Python, and C#, and down more heavily trodden paths with JavaScript and ActionScript. Uncle Chutney's mantra, "Big things are made up of lots of little things," is the key.
So what does this mantra mean, and how does it relate to troubleshooting? In essence, the sentiment is a comfort. Don't worry if an obstacle looks too difficult: break it down into smaller pieces and take another swing at them. As you move through each sub-obstacle, if you run into something that looks too difficult, break it down again. Big things are made up of lots of little things! Eventually, you'll arrive at a scenario in which the obstacle is truly small enough to conquer.
Read on for my first example.
I was recently working on a custom user interface (UI) component for a client. This was a lightweight tab bar for use in a custom video player. The tab bar needed to be configurable for overall width, and of course for whatever changeable number of tabs it should hold. The tab labels should be left-, center-, or right-justified. Tabs should either be just wide enough to contain their own labels, or all the same width (an even split among all tabs present). In Figure 1, you can see a plain-looking prototype in progress.
Figure 1 My custom TabBar component, in progress
Clearly, I had a lot of ground to cover, but all the configurable options were exactly the sort of challenge I enjoy (at least, while wearing my programmer hat). So I jumped right in, and immediately made my first mistake: I set out to create the ultimate goal, the Big Thing (the tab bar), as opposed to creating Lots of Little Things that would cooperate to eventually meet the project's requirements.
My idea was based on basic principles I've been taking advantage of for years. I would create each tab from a combination of the same three parts, to provide for the greatest flexibility in graphic design. Every tab would contain a left piece, a resizable center piece, and a right piece, as shown in Figure 2. This way, a designer could create whatever look was desired — from rounded, to angled, to flat end pieces — as long as the center piece could be stretched without harming the visuals.
Figure 2 Each tab would contain three pieces (plus a text field for the label)
Tip: I entertained using 9-slice scaling (see Tom Green's "9-Slice Scaling in Flash"), but that feature is only available to Flash Player 8 and higher, and I wanted to support players as early as Flash Player 6 (the first player to support ActionScript 2.0).
For this particular piece of the puzzle, my goal was pretty straightforward (or so I thought). The three pieces of each tab, plus its dynamic text field, would reside in a container movie clip. Within the tab bar itself, I would reference each of its tabs in turn and instruct the center piece to stretch as wide as necessary, using the MovieClip._width property to accomplish that goal. Then I would position the right piece at the same distance from the center piece's left edge, using the MovieClip._x property to do so.
In a nutshell, the relevant ActionScript 2.0 would look something like this:
tabContainer.tabCenter._width = 200; tabContainer.tabRight._x = tabContainer.tabCenter._x +200;
Code 1 Basic ActionScript to stretch the middle piece and position the right piece
I didn't even stop to test this approach, because it was such an obvious choice. Barrelling forward, I added the features to allow for left, center, and right justification, for varying tab widths, and all the rest. You can see a stripped down working example (complete with buggy behavior!) in the tab_error.fla file that accompanies this article.
Getting ahead of myself like this was a bit like the overconfident antics of the Hare in Aesop's famous "The Tortoise and the Hare." Rather than following the adage "Slow but steady wins the race," I found myself hundreds of lines of code later, only to discover that my tabs looked like the broken widgets in Figure 3.
Figure 3 Something has gone wrong, but what?
Clearly, something was wrong, but what was the cause? Could it be that my text fields were too long? Maybe they were pushing the right end pieces too far past the right edges of the center pieces. That was a decent hunch, and testing the hypothesis was easy. I temporarily set the TextField.border property of each tab's text field to true, which let me see how big the text fields actually were. Figure 4 shows what I saw. Clearly, the text fields were good and snug, and therefore not to blame.
Figure 4 The text fields aren't too long ...
Thus began my journey toward finding the culprit for the right-hand gaps. As Uncle Chutney tells it, the name of the game is to isolate the problem. That is, examine the issue and try to separate it from the distraction of the code around it. As a rule, this is easier to accomplish when you engage in a repetitive, Tortoise-like cycle of "code a bit, test a bit" from the get-go. But even if you've already raced ahead hundreds of lines without testing, it's still possible to "lift" the problem from its surroundings. It just takes a bit more work.
Often, you'll find that it helps to save your current FLA, start a new one, and then rebuild a simplified version of the trouble spot from scratch. In this case, it meant starting from the very beginning: a new FLA, a square converted to a movie clip symbol, and the MovieClip._width property.
Keywords
Flash, ActionScript, troubleshooting, debugging
