Home > Best Practices, Flex, Opinion, Random Notes > When and how to use mx_internal in Flex

When and how to use mx_internal in Flex

March 12th, 2009

How many times have you hopped into Flex’s source code only to see the modifier “mx_internal”? No public, private or protected, just mx_internal. It is everywhere in there. But what is it? Turns out, according to Adobe, it is a namespace used to flag functions and properties within the framework that may change in future releases. Obviously, since they might change, Adobe, with all its motherly goodness, hides these properties and functions from us behind this namespace. This does not mean we cannot access them though. We just have to jump through a few small loops. This article will go over how and when to use mx_internal, but also what to be careful about when using them.

How to use mx_internal
Using it is pretty straight forward and simple. All you have to do is include these lines :

import mx.core.mx_internal;
use namespace mx_internal;

and BAM! You now have access to mx_internal. Another way you can access it is like this:


I prefer this method myself*. It allows whomever is looking at the code that you are accessing something marked mx_internal vs doing a blanket import. This is a pain whenever you come back to your code and you dont realize what is using mx_internal and what is not. It will make the code a little more cumbersome, but it does help for clarification purposes. I suppose you could always put comments next to your code that uses it, but its my experience that no one really comments properly (including myself).

What do you get when you use mx_internal
It is kind of nice when you use mx_internal for the first time, because you are given access to all sorts of new things within a component that you did not have access to before. Here is a easy way of showing you. These are some properties within a panel that you have access to normally:


and with mx_internal turned on, you now have these:


As you can see, there are all these new fields you have access to, which are marked with the yellow rhombus.Isn’t that great? All these new properties waiting to be explored. Lets take a look at what we can do with some of these.

Examples with mx_internal
I saw this example somewhere else, but it is a nice easy example that involves the NumberStepper component, which consists of a TextInput and two Buttons (for stepping up and down). What is annoying is that you can type whatever numbers you want in that inputBox. What if I want to make it so you cant edit it? I could try that enabled property on there, but that disables the whole thing. I dont want it disabled. Unfortunately, we are not given direct access to this component. Luckily we can still get to it via mx_internal.

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
   layout="absolute" creationComplete="complete()" >
       public function complete():void{
         stepper.mx_internal::inputField.editable = false;
   <mx:HBox id="hbox">
     <mx:NumericStepper id="stepper" />

If we do this, we will still be able to change the values via the buttons, but you will not be able to physically edit the values inside of the TextInput. Speaking of buttons, are you bored with those up and down arrows? Well with access to the mx_internal, we can change those icons.

private var redIcon:Class;      
public function complete():void{
  stepper.mx_internal::inputField.editable = false;

giving us this:

I added a red.png (a small red square) to our project. After that, I added the following lines to our program and complete() function, giving us a fashionable look to our new buttons.

Of course, this is for the sake of example. Your buttons in real life would much better. Here is another example I dug up. Creating Alert boxes with non-selectable text.

public function complete():void{
  var a:Alert;
  a = Alert.show("Hey Look text!!", "i cant select it!", Alert.OK | Alert.CANCEL);
  a.mx_internal::alertForm.mx_internal::textField.selectable = false;

Once again, the alertForm within the Alert object has a textField on it. We are simply using mx_internal to each it.

The pain of mx_internal
Before I mention the obvious problem, here is what is kind of a pain. These are things that Adobe does not officially support. It is not like these are properties they let you know about in advance. Most of the time, you will have to dig down into the source of Flex to see what is available to you. Alternatively, you could just use mx_internal and scroll through your new properties as well, but I prefer looking at the source.

One way to help you find things you have access to is to remember that most of the build in components are Composite Components, which are components built from one or more components. The NumericStepper is a perfect example. Just by looking at it, you know you have a TextInput and two Buttons.

Of course, a quick hop into the source, you can see within the createChildren() method what components are being added to it (you might remember from this post what createChildren() is and how it is used) . Once you reference them via mx_internal, you can just treat them as if they were normal components.

The obvious pain is directly from what Adobe tells us in the Flex docs.

mx_internal is a namespace used by the Flex framework to partition out functions and properties that may change in future releases of the Flex SDK.

Yep. Whatever you use with mx_internal IS SUBJECT TO CHANGE. This is why it is hidden away from us. However, I do have a hard time believing they are going to replace a TextField within the NumericStepper. I suppose in Gumbo or a future release of Flex, they might have an AdvancedTextField and use that instead? I am just thinking out loud.

Personally, if I can avoid it, I try to keep mx_internal out of a framework. If it is a framework that is going to be continued internally, that is fine. You could always fix it. If you develop a framework that is shipped off to the client for their use and that mx_internal DOES in fact change, be prepared to have an angry client.

Whenever I get a chance to mess with mx_internal(which is not often), I feel like I am exploring a dangerous uncharted land. I am fairly unfamiliar with those parts. You have to be careful with it. However, you do get to do some pretty cool stuff! While it may be a mystery right off the bat, it is incredibly easy to dive into to play around with.

There is another reason why this is the preferred method to use. If you look at the example I gave with showing the new methods in the intellisense, I used an Panel. If you try to do the same thing with the NumericStepper, you will notice they do not show up there. The only reason I can come up with is because the components that DO NOT show the mx_internal fields are already using the mx_internal namespace. If this is incorrect, by all means, please correct me!

Best Practices, Flex, Opinion, Random Notes ,

  1. April 14th, 2009 at 18:30 | #1
  2. October 13th, 2009 at 21:45 | #2

    Hi Marcel, thank you for contribute to our comunity. This post was enlightening!

  3. RK
    October 30th, 2009 at 04:59 | #3

    Hi Marcel, thank you for this wonderful article.

  4. Nick
    April 28th, 2010 at 17:06 | #4

    Wow..THIS WAS SOOOOOO HELPFUL!!!! ZOMG..I’ve been looking for this all day! CodeOfDoom is now my homepage.

  5. June 15th, 2010 at 02:07 | #5

    Superb – that’s cleared a few things up! Good article!

  6. Anonymous
    January 25th, 2011 at 22:34 | #6

    thanks, nice article.

  7. Nazeer
    March 2nd, 2011 at 15:18 | #7

    This is a great article, simple and much clear. However, I have a concern, what if we moved to advance flex framework that may not support some of the function and property used in the existing project. Am I stuck with original SDK? / Do I have to re-design to implement the missing items?. Other big challenging is to tracking the used mx_internal.

  8. May 19th, 2011 at 03:17 | #8

    I found your site thanks a Google search. You have done a fine work. And it’s really nice to read you. I’ll definitely be back! :)

  9. abderraouf
    December 28th, 2011 at 11:14 | #9

    Thanks a lot!
    I ask if i can define my own namespace. i’ve searched in the net in vain.

  10. Jacob Cabral
    January 28th, 2012 at 22:53 | #10


    Congratulations for your great article!

  11. Amit Tamse
    March 18th, 2012 at 01:03 | #11

    It was worth to learn from your site. Thanks a lot for publishing the article.

  12. November 17th, 2012 at 01:42 | #12

    I’ve said that least 119888 times. SCK was here

  1. August 30th, 2010 at 17:57 | #1