This has been a source of frustration for such a long time, I had to share the solution. Credit for this one goes to Martin McBrearty, and there are a few other blogs out there that support this method.

Important Disclaimer: This method does not appear to be officially supported, and is not guaranteed by me or anyone else to work. Use at your own risk!

[More]

Today I spent hours tracking down a bug related to inserting and/or deleting data from a Tree control. In certain circumstances, an update to the underlying dataProvider would cause the following to be reported:

After a bit of Googling, I found that I am not alone. Other folks have the same issue with Tree. Even more common, it looks like people are getting the same error when manipulating data in an AdvancedDataGrid, in which case it is reported as:

After drilling down into the Flex Framework source and exploring the makeRowsAndColumnsWithExtraRows function, I added some watch expressions in the Flash Builder Debug pane. (The debug features are really, really useful for this kind of thing.) The culprit? The value for verticalScrollPosition was being reported as -1, causing a line of code to look for an array element at index -1. This array element was in turn undefined, so the error message suddenly makes perfect sense.

The real puzzler here is that verticalScrollPosition could ever be less than zero. This is the logical equivalent of scrolling to the top of the list, then scrolling up one more spot, which is of course impossible. In any case, I have decided to assume that -1 is invalid at all times, and that -1 really means 0. I hope that is a safe assumption!

So, the solution is simple. In my case I had already subclassed the Tree control. If you're using the stock control from the framework, you'll need to subclass it and simply add the following:

All it does is intercept any request for verticalScrollPosition and guarantee that it is greater than or equal to zero. In brief testing, the error has disappeared and I have seen no side effects.

Like anything else on this blog, use this fix at your own risk, since I can't guarantee it won't have any negative impact.

Happy coding!

I recently took on the task of a major refactor of an AIR project. The application had grown into a monolithic beast with lots of conceptually related but logically disparate functionality. Management of the code was becoming a challenge. Packages were poorly structured. It was a mess.

The real catalyst for change, though, was the compile time. It had gradually crept up from a few seconds to 30+ seconds. In an effort to return to acceptable levels, I broke out chunks of UI into modules within the main project. I pulled graphics and sounds assets into a separate library SWC. But there was no appreciable effect.

The plan of attack was to break out at least two sections of the application, which are essentially mini-applications on their own. They share only a few common aspects of the main application, such as a common model and server connection manager, and are otherwise self-sufficient. Luckily, the project is built on Cairngorm principles, meaning that these items are already more or less detached from the view components.

What follows is a set of principles for successfully breaking down a large Flex application into separate, manageable module-based projects. These techniques seemed to have worked for me, although of course it is still a work in progress and there is much optimizing left to do. Really, this post is probably more for me as a future reference than anything else, but if it can help someone else, that would be terrific. Your mileage may vary, and if it does, leave me a comment to let me know what you've done differently!

[More]