I've been playing around with the Tree Component in great depth and have found a few discrepancies which I feel are major pit holes. After a lot of searching, it was also clear that many other developers have come across the same issues. My main gripe: the tree component's support for horizontal scrolling is not very useful. I expected it to work like the ScrollPane's horizontal scrollbar, but it doesn't.

Horizontal Scrolling: The Problem
Now I have a little application that allows you to add and remove nodes to a tree, whooppee. Ok, so what happens if the user adds enough levels to the tree such that they cannot be seen because they run outside of the tree components boundaries? Enter, horizontal scrolling.

The first thing I do is checkout a property which the Tree component inherits from the List component:
Tree.hScrollPolicy

It has two possible string values "on" or "off" - great, so no "auto."

Ok, so hopefully if I just set it to "on" then it should enable the scrollbar when it is needed so that users can scroll them in and out of view. Wrong. What it actually does, is show a disabled scrollbar at the bottom of the component. Luckily, thanks to good documentation I was quickly led to another property of the Tree component that's inherited from the List component:

Tree.maxHPosition

What this property does is specify the number of pixels that the scrollbar will horizontally scroll. In practice setting this value displays an enabled scrollbar that scrolls left and right 'x' amount of pixels even if it isnt needed. So, for the horizontal scrollbar to be useful, you actually need to update the property every time you add, remove or replace an item in the Tree to reflect the width of the widest item - which is a pain to say the least.

What makes it worse is that, when it comes to vertical scrolling, the Tree component automatically updates the size of the vertical scrollbar for you by default, unless you turn the vertical scrollbar off:

tree_mc.vScrollPolicy="off"

So, why not the horizontal scrollbar? I'm not really sure, but I think it has something to do with the component engineers worrying about the speed of the component.

Adding code to find the widest row in the tree wouldn't be hard, however it may become very slow code if you were to have 10,000 rows in the tree and every time you added, removed or replaced an item, that code would have to run again to determine the widest row and then update the scrollbars size. Not a problem if you are only adding one row to the tree, because all the code has to do is check the new row's width and compare it with the current largest row. However, it will be a problem if you are to add say 10,000 rows at once, by changing the dataProvider of a tree, because then you would have to loop through each of those new rows, and looping is very slow, when you have so many iterations. To add to that, you would only want to detect the width of the rows in the tree that are visible, i.e., their parent is open, not just those that are inside the viewable area. Which means you would also have to write code to get a list of all the visible rows and then use that list to determine the widest row. This also means that you would have to execute this code every time a Tree node is opened or closed.

So, I guess what I am saying is that maybe the engineers actually had a valid reason to not include an auto updating horizontal scrollbar. But then I would say, how often does somebody need a Tree component that will display 10,000 rows? Not often, I would imagine, and even if it was high priority to support large datasets, I'm sure there are ways to optimize those routines for speed.

The Solution
My findings were, that there isn't really a proper solution for this, it could get very messy, simply because of the way the Tree is rendered. Let me explain.

An instance of the Tree Component only ever contains "x" amount of row movieclips, where "x" is equal to the Tree.rowCount. So, if I specify Tree.rowCount to be 7 (which is the default), then there will be seven row movieclips created inside the component when it is rendered. This causes problems because ideally we need a visual representation of each row in the Tree to determine its width. In the end I decided to start writing my own Tree component that works how I would expect a Tree component to work.