If you ever had some strange problems with styles in Flex, you might want to know how styles are internally handled and implemented.
Ok this post will not cover too much of all the stuff going on there, but a bit of the basics how styles are finding their way from the css file to your component.

Lets assume that we have a css file with type selectors and class selectors, a module based application and some custom components which are designed the way that you can use them out of the box and that they can be individually skinned and styled by other developers reusing them. That´s what custom components are for, right?

So the first question is:
How are the styles compiled into your swf file?
Assume that they are defined in an external css file. You know you can compile css files to swf files and load them at runtime or simply compile them into your application at compile time with a simple assignment like this:

Here is the content of our simple css:

Button
{
        color: #990000;
}
.myCustomStyle1
{
        color: #009900;
}
 /*
     some additional styles here...
     like Button.myCustomStyle2
*/

That´s what we will use for our example here.

In this case the MXML compiler creates a bunch of classes and inserts the css definitions right into a method called from the constructor in the generated Applications class.

public function StyleExample() {
        mx_internal::_StyleExample_StylesInit();
}
mx_internal function _StyleExample_StylesInit():void {
        var style:CSSStyleDeclaration;
        // Button
        style = StyleManager.getStyleDeclaration("Button");
        if (!style) {
                style = new CSSStyleDeclaration();
                StyleManager.setStyleDeclaration("Button", style, false);
        }
        if (style.factory == null) {
                style.factory = function():void {
                        this.color = 0x990000;
                };
        }
        // myCustomStyle1
        style = StyleManager.getStyleDeclaration(".myCustomStyle1");
        if (!style)
        {
                style = new CSSStyleDeclaration();
                StyleManager.setStyleDeclaration(".myCustomStyle1",
                                           style, false);
        }
        if (style.factory == null)
        {
                style.factory = function():void
                {
                        this.color = 0x009900;
                };
        }
        // similar code follows here....
}

I only pasted the relevant code, so this is not complete but should give the basic idea.
So what happens here?
(Read more…)

At my first posts I wrote about my favorite Flex feature: Databinding
Now I will take a look at the opposite, IMHO the most precarious “feature” in Flex: callLater()

If you have a dodgy problem that a certain property is not available when it already should be and you ask someone at flexcoders you often get the advice, “try callLater” for a quick work-around. Sometimes this helps, but it leaves a bad smell, because often it´s just hiding some other problems in the code.
So when we worked on a large-scale Flex application we have used it sometimes in the beginning, but after a while we decided to avoid callLater. To find and solve the real problem is simply the better solution - and we never needed it again - there was always another solution to solve a particular problem (maybe we just have had luck).

Unpleasantly we get confronted with the fact that callLater is used inside the Framework at the heart of the layout engine.
We struggled with some strange problems. For instance we got a NullPointer exception in the updateDisplayList method of a custom component, which has already been cleaned up properly and removed from the displayList. It turned out that the layout mechanism delayed with callLater an invocation of updateDisplayList but our stuff there has already been removed and threw an exception.
It was not hard to fix, but it demonstrated us that some asynchronous stuff was going on behind the scenes which was out of our direct control.

So for me callLater leaves always a certain bad smell.

Unfortunately I never found time to really investigate how it´s implemented and what are the concepts behind it.
So it was time to catch up with this issue:
CallLater is basically a method in UIComponent which delays a passed function to the next EnterFrame OR Render event.
Often in den docs it´s just described that it will delay to the next frame, which is not correct because it could be that your function is executed already at the Render Event, which happens in the same frame and is the last opportunity where User code can be executed before the screen is rendered.

For more details about the internal concept of a frame in Flash and the relevant events see the great article by Sean Christmann:

Here is a good illustration from his article about the anatomy of a frame in Flash:
(Read more…)