AutoScrolling for Flex Tree

We've been mostly fixing bugs on the SDK as we prepare for the release for MAX, and one of the bugs that was assigned to me was SDK-9645, https://bugs.adobe.com/jira/browse/SDK-9645. The problem was that in a Tree (and other List-based components), when you set the horizontalScrollPolicy to auto, the scrollbars actually don't come out when they should. This seems like a bug at first, but we did this by design for performance reasons. In order to display the scrollbar properly, we need to measure the width of all the items (on-screen or not) and this would just take too much time to do by default. So instead, to get a scrollbar to show up, you need to set maxHorizontalScrollPosition, which is how much the user can scroll. However, this can be annoying, especially as you might not know how big your data is. So I've created a simple component that extends Tree that measures the width of all the renderers so the scrollbars are calculated correctly. In order to do this, in updateDisplayList, which is called whenever we need to redraw, I call measureWidthOfItems, which calculates the max width for all the item renderers. This means that redrawing takes some more time and is a little slower. Anyways, here's the code:

package{
    import flash.events.Event;
   
    import mx.controls.Tree;
    import mx.core.mx_internal;
    import mx.core.ScrollPolicy;
    import mx.events.TreeEvent;
   
    public class AutoSizeTree extends Tree
    {
         public function AutoSizeTree(){
              super();
              horizontalScrollPolicy = ScrollPolicy.AUTO;
         }
        
         // we need to override maxHorizontalScrollPosition because setting
         // Tree's maxHorizontalScrollPosition adds an indent value to it,
         // which we don't need as measureWidthOfItems seems to return exactly
         // what we need.  Not only that, but getIndent() seems to be broken
         // anyways (SDK-12578).
        
         // I hate using mx_internal stuff, but we can't do
         // super.super.maxHorizontalScrollPosition in AS 3, so we have to
         // emulate it.
         override public function get maxHorizontalScrollPosition():Number
         {
              if (isNaN(mx_internal::_maxHorizontalScrollPosition))
                  return 0;
              
              return mx_internal::_maxHorizontalScrollPosition;
         }
   
         override public function set maxHorizontalScrollPosition(value:Number):void
         {
              mx_internal::_maxHorizontalScrollPosition = value;
              dispatchEvent(new Event("maxHorizontalScrollPositionChanged"));
           
              scrollAreaChanged = true;
              invalidateDisplayList();
         }
        
         override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
         {
              // we call measureWidthOfItems to get the max width of the item renderers.
              // then we see how much space we need to scroll, setting maxHorizontalScrollPosition appropriately
              var diffWidth:Number = measureWidthOfItems(0,0) - (unscaledWidth - viewMetrics.left - viewMetrics.right);
             
              if (diffWidth <= 0)                     maxHorizontalScrollPosition = NaN;                else                     maxHorizontalScrollPosition = diffWidth;                                     super.updateDisplayList(unscaledWidth, unscaledHeight);           }      } }

[Code updated 3/20/09] Because we're doing this extra calculation, it means for a Tree with a lot of items, we may become slower. There are better ways of doing the same thing besides measuring every single renderer in updateDisplayList(), but this is definitely the easiest way. If performance is really a problem with this, let me know, and I'll try to come up with something a little smarter. Below is an example, with the top one being the new AutoSizeTree component and the bottom one being the old one. Notice how the top is a little slower when resizing with an effect (this shows it's a little slower when laying out in general) when lots of the items are open. [Post updated on 3/20/09 to fix an issue: SDK-18499]

Re-Introduction

For some technical reasons, I had to repost this introduction, but I'm also going to start blogging for real now. I have Internet at home, and we're getting a little more free time at work as we're almost done bug fixing for the next release. Anyways, on to the introduction.

Who are you? I am Ryan Frishberg, and I just graduated from Carnegie Mellon University. In July, I moved out to the Bay Area and started work at Adobe on the Flex SDK team. I’ve always been interested in software development and web technology, and Flex is absolutely awesome.

Why are you blogging now? Since I’ve tried to stay on top of the Web 2.0 and Rich Internet Application world, I read way too many blogs each day. I found out that through all the jargon propaganda they give you (don’t worry, I’ll be dosing out similar content soon), the blogs are actually useful. In fact, about half the time I Google for a technical question, I end up going to a blog. So I hope that by starting this blog, I can contribute to some of the technical knowledge (as well as the proper jargon and propaganda) out there. Also, I just started working on Flex, which means that I’ll have some really cool issues to talk about

What will I talk about in the blog? I would like to talk about web technologies, especially Flex. I’ll give examples on using Flex for beginners to show you how easy it is to create something useful in the framework. I also hope to cover more advanced topics that aren't covered as much by other blogs, like bugs I'm currently working on or limitations to the framework.

Content is on its way soon, and if you want to reach me with any questions, feel free to contact me via email.