If you have ever peered into one of the mx classes, you will probably have noticed the ubiquitous mx_internal namespace being used. For those of you not familiar with the usage of namespace, it is basically a system of allowing classes to peer into other classes for needed code. The most common namespaces are:
publicprotectedinternalprivate
So the mx_internal namespace is a kind of extension of the internal namespace, but rather than being limited to seeing other internal properties and methods of just a particular package, it is able to see code through out the entire mx framework. For example, the Panel, which resides at mx.containers has mx_internal function getTitleBar(), which makes the protected var titleBar visible to any other component within the mx framework.
So what can this do for you as a component developer. Well, you can easily tap into these methods and properties yourself. All you need to do is add two lines of code to your class.
include mx.core.mx_internal;
and
use namespace mx_internal;
Now any property or method with the namespace mx_internal is accessible to your class. But be forewarned, there are two issues with doing this.
- Adobe has written in their code the following caution:
This namespace is used for undocumented APIs — usually implementation details — which can’t be private because they need to visible to other classes. APIs in this namespace are completely unsupported and are likely to change in future versions of Flex.
This means you might be in for a surprise the next Flex SDK update you do.
- You don’t get code hinting in your IDE since technically speaking you are not even supposed to be implementing these APIs.
Anyway…hope this might provide some solutions to any component developers out there that are stuck with a particular extension problem.
[EDIT 2007.05.14] – A buddy of mine found a cool but not-so-OOP way of accessing a component instance’s mx_internal properties. I would be very careful with getting into the habit of this. Check it out.
8 Comments so far
Leave a comment
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Just found your blog, lots of good posts on here. I’m not sure if you go to the Boston Flash User Group, but lots of Flex folks there if you’re interested. Anyways, as for point #2, the reason for this is actually because Flex Builder doesn’t deal correctly with any namespaces. So if you create your own namespace, it won’t correctly code-hint for it either.
Comment by Brian Thursday, March 29, 2007 @ 3:09 pmThanks for the comment. I have heard of BFPUG but haven’t gone to it yet. I plan to someday soon.
Also thanks for the tip on namespaces. I didn’t know that since I rarely use them, however that makes alot of sense for why it doesn’t code hint. Maybe in Flex 3?
Comment by jwopitz Thursday, March 29, 2007 @ 3:14 pm[...] Posted April 3, 2007 A colleague points me to this blog by Justin Wopitz (Maiden Rulezzzz!), a good summary of what the mx_internal namespace is used for. I’ve [...]
[EDIT]
Pingback by mx_internal... Boo! « Good, Fast, Cheap Tuesday, April 3, 2007 @ 9:12 pmNot a biggie, but the name is Justin W. Opitz
Cool post. Inspired me to share an experience I had with needing to use mx_internal, here: http://chrisluebcke.com/2007/04/03/mx_internal-boo/
Might be useful for somebody someday.
Comment by cluebcke Tuesday, April 3, 2007 @ 9:22 pm[...] Tap into the mx_internal namespace. [...]
Pingback by Tips (and reckless behaviour) for Component Developers « jwopitz - flex/flash exploration Wednesday, April 25, 2007 @ 9:29 pm[...] 14th, 2007 You may have remembered a post about tapping into the mx framework awhile back. Basically I was griping about Adobe’s excessive use of private (instead of [...]
Pingback by An Ugly, Anti-OOP Way to Infiltrate the MX Framework « jwopitz - flex/flash exploration Monday, May 14, 2007 @ 8:23 pm[...] Adobe’s ActionScript 3.0 Language and Components Reference Adobe’s Flex 2 Language Reference Flex and ActionScript Error Codes Wiki Good, Fast, Cheap Oscar Trelles jwopitz – flex/flash exploration [...]
Pingback by Professional Monkey Keyboard Operator » Blog Archive » Sharing Links Is Good Karma Friday, June 1, 2007 @ 6:31 amvery interesting, but I don’t agree with you
Comment by Idetrorce Saturday, December 15, 2007 @ 11:38 pmIdetrorce