explorers' club

explorations in dev, science, sci-fi, games, and other fun stuff!

Tip: Tapping into the mx framework for component development


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:

  • public
  • protected
  • internal
  • private

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;


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.

  1. 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.

  2. 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 thoughts on “Tip: Tapping into the mx framework for component development

  1. 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.

  2. Thanks 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?

  3. Pingback: mx_internal... Boo! « Good, Fast, Cheap

  4. 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.

  5. Pingback: Tips (and reckless behaviour) for Component Developers « jwopitz - flex/flash exploration

  6. Pingback: An Ugly, Anti-OOP Way to Infiltrate the MX Framework « jwopitz - flex/flash exploration

  7. Pingback: Professional Monkey Keyboard Operator » Blog Archive » Sharing Links Is Good Karma

  8. very interesting, but I don’t agree with you

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s