Category: Flash

Skip to the last sentence for the advice.

Many Flashers already know about the caveats one faces when going from Flash Player 6 to Flash Player 7 development in dealing with case sensitivity. This new feature helps speed, and also allows for more freedom of naming in code since color can now be an instance of the Color class. Additionally, one mispell of mY_btn (instead of my_btn), will have the Output gettin’ all in yer face about “Yo, this variable doesn’t exist anywhere man… weird, what’s he doing here?”. It’s nice to know an uppercase Y makes one so distinctive. How about a capital J, biotch!?

Anyway, re-writing some AS1 XML parsing code, and it was working fine when I published to Flash Player 6, but not 7. I was like, wtf. So, started debugging, making mad traces, long debugging window sessions, digging deep in XML objects in the Debug Window to inspect each and every property.

Turns out, someXmlNode.attributes.href is different than someXmlNode.attributes.HREF. You may go, “No sh… thanks for wasting 3 paragraphs of my life Jester.” If your still here, you r0x0r. Ah… but is href a variable or a string? Attributes in XML have the neat distinction of being neatly placed on a vanilla object called “attributes”, so you can access them like you would any other plain object, such as a data provider item (item.label). Because they are vanilla, though, you typically don’t have classes defined that represent them. For instance, EventDispatcher, when it does a dispatchEvent, throws out an object. You’ve seen the familiar syntax:

dispatchEvent({type: “event”, target: this});

It’s just “known” that you make at the very least a type attribute, and usually a target. The “known” attitude is what led us from Flash MX to Flash MX 2004. No more mispellings of variables, objects… we now have real-world syntax checking!

But again, you can’t for vanilla, one time use objects like EventDispatcher and the XML Object’s attribute construct do. Therefore, one must be extremely careful. For the knowns, like label and data, or for events like type and target, your fine because everyone and their mom knows you type it in lowercase.

However, for some events, they aren’t. For instance, all UIComponents get “focusIn” and “focusOut” events. See the capitalized In and Out? Tricky, tricky…

XML is even worse. The second you utilize an attribute, you’ve immediately hardcoded your code. Now, as a seasoned Flash developer, I’m cool with that. XML parsing is my daily bread, and it’s just known that you quickly navigate your document to get the data in. Some people think that using recursion is more encapsulated, but that is dangerous as hell in Flash, can be slow for large objects, and if your in your Model class, who gives a flying flizz-narg?

So, just some advice. When parsing XML attributes, make sure your capitalization in your XML node’s attributes (or internal structure) is the same as what your using in your code.

I can’t even think of a correct title. If you have a Flash hyperlink in an input text field that displays html with an href of “asdf” and a target of “”, and Firefox Preview Release 1.0 is your default browser, and you click the link, it’ll open the browser. The first tab will be blank. The second will go to a Microsoft Support Link, but it has a local path to your current working directory in the url field + “asdf” at the end.

Working on some side stuff Friday, and over the weekend, and had one hell of a time tackling focus in my custom components.

First off, I use my own custom class as a layer between mx.core.UIComponent and my components classes. I do this because:
– I like Grant Skinner’s GDispatcher better than EventDispatcher, although, I rarely utilize custom methods much, I still like the option to do so.
– one thing not implemented into UIComponent was removal of the deadPreview movie clip like FUIComponent had back in MX; I implement this so I can include a dead preview in my components (since I rarely make an SWC’s for my own components), and I’d prefer to see something beyond a white dot to indicate what a movie clip is on the stage.
– I “finished” the implementation of drawRect to have rounded edges. The drawRect method for UIComponent has radius documented as a property, but it wasn’t implemented.

…however, after using this for …geez, maybe a year, I ran into a problem by overwrriting EventDispatcher’s addEventListener with my GDispatcher’s implementations. When a component gains focus, it fires onSetFocus, and when it loses focus, it fires onKillFocus. These functions inside of UIComponent add and remove listeners for key up and down. I didn’t know why my listeners weren’t getting fired until I realized I was overwriting the methods.

After fixing that, it was pretty nice that a component already listens for it’s own events of keyUp and keyDown when it has focus.

Secondly, I didn’t know until re-reading the class file for the umpteenth time, but you must implement pressFocus in your onPress function, and releaseFocus in your onRelease functions.

Finally, the obvious of focusEnabled = true, tabEnabled = true, and tabChildren = false being set in your init. Additionally, the Halo rect (a green rectangle) won’t draw around your component correctly unless the width and height are validly set. I usually do a setSize as the last call in my init function with default sizes, and pass true in as the 3rd parameter to prevent an event from being generated.

I haven’t figured out how to kill focus completely from everything yet, but these gotchas took a while to get used to.

Oh yeah, and if you want to tab to components within a component, don’t forget:

tabEnabled = false;
tabChildren = true;

It’d pretty nice, once you figure this stuff out, how much stuff is done for you. Hope this helps you all.

If anyone finds out about killing focus, let me know.

var f = getFocusManager();
f.setFocus(null);

…does NOT work, hehe.

Had some interesting discussions and observations over the past few weeks. This culminated yesterday into a conversation about games, etc. It just was luck that I garnered an understanding of both of the above comparisons.

First off, I can see why a lot of applications are going web vs. fat client/win32 etc. I like to think of myself as an applications developer vs. a web developer, as most of my Flash stuff for companies (not contract) tends to run on the client machine via some form of client. All of my contract work is for a website in some form or another, with the exclusion of some rare “niche” fat client projects.
(more…)