First, let me say I am sorry. A year or so ago, I wrote these VectorCollection classes. They are not spectacular works of art, they are very basic implementations required to use Vector inside of Flex components which are looking for IList and ICollectionView for their dataProviders. Vector has some performance advantages in some cases (for more details, take a look here. ) but overall, the big advantage to me is type safety. I know what should be in the Vector and flash knows if I mess that up. On the whole, these are simple implementations that don’t solve every problem I would love to solve if I had the Flash Player source and some time, but they will allow you to use Vectors more directly in Flex. So, if you find them useful, then enjoy. private var source:Vector.<uint>; source = new Vector.<uint>; private var vc:VectorListCollection; vc = new VectorListCollection( source ); var sort:Sort = new Sort(); var field:SortField = new SortField( null, false, false, true ); sort.fields = [field]; vc.sort = sort; vc.refresh(); File Available Here Cheers, Mike

Dependency injection with Flex UI components can be tricky business. Not just doing it, there are a lot of strategies for that, but to do it without causing performance degradation and unnecessary work on the part of the framework and ultimately flash player. To understand why, we need to discuss a bit about the whole component life cycle.

When a component is first instantiated, its constructor is executed and any local variables that might have been declared with initial values are set, etc., but the most important stuff… the stuff that makes a component a Flex component hasn’t happened yet and it won’t anytime soon. Properly written Flex components do the balance of their work after they are added to the display list. Back when I first started yapping about this stuff most of these life cycle methods weren’t well known, but today there are a lot of great resources on them, so I am just going to stick to the basics.

The methods I care about are createChildren, measure, commitProperties and updateDisplayList. Each of these methods is called by the Flex framework after the component is on the display list. With the exception of createChildren, you can almost think of these methods as being scheduled. They get called by the framework, at an appropriate time for optimal Flash player performance, if the component itself or some outside force deems it necessary.

To take advantage of this scheduling and to ensure you don’t have timing issues, a properly architected Flex component waits to create any static visual children until the createChildren method is called. It waits to make visual changes to the component until the updateDisplayList method. When a property is changed on the component that could affect one of the components children, i.e. the textinput inside of a datefield, the component saves off this change and applies it when commitProperties is called. Finally, the component aggregates information about its size and reports it (but never, ever changes it) during the measure method.

The reason I mention all of these things is that there is a fair amount of work that starts happening the moment the component is added to the display list. From that point on, all of these methods are called and changes to the component, especially those involving the amount of space it takes on the screen, can cause major amounts of rework. (If I change the size of a button in the middle of the page, I may need to size and layout the whole page again). You would never know this from the Adobe docs, but the creationComplete event is likely the worst place you can do many things and that is for this same reason. Everything is sized, positioned and ready to do… then you cause it all to change again.