I found something funny the other day when inspecting Flash Player’s built-in SimpleButton, a standard member of the display list. Or I thought it was standard.
SimpleButton isn’t a DisplayObjectContainer, so it doesn’t have methods like addChild() and getChild(). Instead it has convenient button states, such as the upState property, that contain children in a different way than DisplayObjectContainer. Which made me pause.
DisplayObject.parent is typed as a DisplayObjectContainer, both in the documentation and when analyzing the class through describeType() (reflection). So what is the value of the parent property when a display object is added to a SimpleButton? It’s the SimpleButton instance, a non-DisplayObjectContainer! Test all day long if you like, the parent property is very clearly typed to the container but just as clearly returning a different type. I now relinquish all claim to understanding the Flash Player and how it works.
I just got word that I can pick up our Flight t-shirts on Friday. Provided by ZenPrint these bad boys were designed by Bryant Robertson specifically for the 360|Flex Conference (if you haven’t registered yet you better get tickets). The ZenStudio design tool was built on an earlier version of Flight and the ZenPrint guys have graciously offered to sponsor the project at the conference. Thanks again, you guys rock! And of course props to our designer, we’re told we have the coolest logo of any other framework.
Flight is an application framework for ActionScript 3 (Flash & Flex) - you can read more about it on the website. My brother Jacob and I will be handing out the shirts and some print material at the conference where we’re making some announcements for the Flight Framework.
Hope to see you there!
I always wondered where I would end up using custom namespaces in ActionScript 3. Now that I’ve been using them I have found a few bugs and gotchas, tips and tricks, and now I generally understand namespaces better (or think I do).
(when reading this article it will help if you already have some familiarity with namespaces in Flash & Flex. To learn more about namespaces awesomeness, John Lindquist has an excellent video post that covers the concepts really well and goes into some advanced topics)
To start with I’d like to present a unique review of namespaces concepts (this isn’t pasted from the documentation, so it might be either 1-more helpful or 2-just plain wrong). There are reportedly 5 types of namespaces, but I’m going to say there are only 4 (this is the helpful/wrong portion).
(more…)
Jacob has been in an awesome groove lately, coding his own design engine because I’m too frustratingly indecisive to settle on my own implementation. I’ve been picking at a graphics-skinning-component-media library for way too long, always “just for fun”, so of course it hasn’t gone far. Now I’m jealous of his progress … I’m going to have another run at my own. I hate being inspired by competition (only), but it’s such a motivator - maybe from being the younger brother.
Gauntlet thrown, code spewing, I’m comin’ in!
And thanks Jac.
My daughter, the newest Mac addict. She’s pretending to work like her dad.
The challenge:
The Flash Player has evolved through the ages to provide the most needed functionality. Through each version there have always remained a few common goals. What I have found is that:
Flash is small — from the player itself to the swf file format to the assets it is optimized to load, focus has been placed on small file sizes (this of course is not as apparent in many websites that are heavy in multimedia)
Flash supports standards — the player supports many web and multimedia formats standard in the industry, such as jpg, mp3 and xml
Flash is interactive — the players greatest strength is the dynamic behavior through ActionScript to allow user interactivity
MIDI, a music standard format that most computers support today, fits all of these categories (like a glove). (more…)
CODE: XT is here!
Posted by xtyler in General on 11 15th, 2005 | no responsesOften, in certain environments, a system of codes will be established to help improve communication. They confine advanced concepts into a more concise representation. Code: 51 is commonly used at mediaRAIN to mean something like, “making things not lame†(direct translation is inappropriate for public postings). “Code 51!” is heard when a developer has just qualified his/her code for the Daily WTF. Codes often represent common problems. As a Flash developer I have found the need for a new code. (more…)