When creating custom components, a lot of times it’s just easier to extend existing controls. For example, creating an auto-complete text field isn’t so hard; if you extend mx.controls.TextInput, the only code you have to write is for handling creation of the popup, and handling keyboard events.
The problem is validation. It’s an extremely complex process that works in many passes. In Flash MX 2004 and 8, it was constructor, init, createChildren, draw, and size. There were other minor, but integral functions in that process, but basically it comes down to create it, set it’s default properties, and render the mofo. This strong arm approach didn’t scale to Enterprise apps very well.
Enter the Flex framework. They further fine tuned the invalidation routines. Not only could you defer sizing and drawing to the next redraw event in the Flash Player, but all kinds of properties and styles. If you’re a seasoned Flash Developer, you know if stuff appears “not ready” you just wait a frame… or two. In Flex 1.5, things are no different. Typically, you can use a doLater (or 8) with simpler recursions for a lazy approach, or you can find what properties in particular start the process as most are pretty blatant (anything that calls invalidate).
I may sound like I’m bashing it, and I am, but it truly is valuable. Drawing once per redraw is better than attempting to draw 300 times a second when you can only draw 30 times a second. This is before refactoring and optimization of course. It’s just it’s extremely confusing the nuances of how those affect those extending the framework classes. You shouldn’t use Composition over Inheritance because you’re afraid of extending a class, instead feeling more secure by wrapping your own proxy methods around it as a safety net.
As a component developer, you may think you can take advantage of this, and you can. All the plumbing is held mostly in mx.core.UIObject and all his CSS and LayoutManager friends have hooks nicely integreated. The problem is mixing methods that redraw your GUI immediately vs. later. So, if you write methods that draw your GUI, and mix invoking them elsewhere with doLater’s, you can get unexpected results. The reason for this is that doLater’s are added to an array, and dealt with next screen redraw. After they are dealt with, they no longer exist.
I ran into a situation today where I was calling doLater in a class that extended TextInput, and they’d disappear off into the ether. The reason was, the method I was calling before was setting the “text” property. This is a getter / setter that actually causes invalidation. I’m doing the exact same thing in 2 places; calling a method that causes invalidation and then immediately calling a doLater after it. The only reason the second one fails is because the onEnterFrame spins off into the ether. The cause? Not sure. The first method is called when the internal component fires the enter key presseed event. The latter, broken, method is called in response of a List control being created in a popup being clicked on.
My guess is, the List emitting an event, and immediately being destroyed via a call from a Delegate scoped function somehow ticks off the internal guts of the UIObject, confusing it’s scope, and thus refusing to deal with the methodTable. Meaning doLaterDispatcher is apparently never fired even though onEnterFrame is happily chugging away, 21 times a second, doing nothing useful, eating CPU cyles.
My fix? Make all methods excluding the invalidation causing one to use doLater. Since there is no operator, similiar to public and private that goes something like “causesinvalidation”, I’ll just have to be extra mindful when extending controls that if I’m doing something that will cause multiple invalidations, I’ll have to provide a better conduit, such as a funnel method (you wanna redraw, you call me), or some other proxy.
Bottom line, if you doLater’s are failing to fire, try converting all functions to a doLater and/or indentifying what property you are setting / method you are calling that is causing the invalidation and tread around it.
…or build your own invalidation. Make a movieclip, make it’s onEnterFrame call your function via closure, and then immediately have it remove itself. This has worked flawlessly since Flash 4.