Gordon Smith of Adobe had this to say about mx_internal:
"Anything in the mx_internal namespace is not officially supported and may go away in a future release without notice."
In other words, if you use mx_internal and your code one day breaks, don't say nobody warned you.
If this doesn't scare you, then something like the following has been making you bang your head against the wall for a while:
mx_internal function getSomethingUseful() {
return exactlyWhatIWant;
}
// or
mx_internal var variableIReallyWant;
What to do now?
First go read about namespaces. mx_internal is a namespace. If you know what a namespace is, great. Otherwise I would read up on it.
Now that you know what a namespace is and how to use it, you don't need my help anymore...but for the other 90% that didn't read up or are like me and just need to see it in action once, here's an example:
import mx.core.mx_internal;
...
use namespace mx_internal; // put right after import statements
Seriously, that's it. Sure the function/variable still doesn't show up in intellisense, but try to access it anyway. The compiler won't throw and error and your code will work. Alternately you can also do this:
import mx.core.mx_internal;
...
componentInstance.mx_internal::variableIReallyWantToSet = valueIWantToSetItTo;
// or
mx_internal::variableIReallyWantToSet = valueIWantToSetItTo; // same as using this.mx_internal::variableIReallyWantToSet
Then again, if you had read up on namespaces, you'd already know that.
Go forth and be merry...and hope Adobe doesn't change anything you've used.
1 comment:
I can see the point of mx_internal for certain scenarios but my biggest complaint about the flex source code is that both mx_internal and private accessors are littered throughout the code in places where it is inapropriate and this can make your life damn hard as a developer.
Post a Comment