Developing For .NET

In yesterday’s post, Fun with WPF ScrollViewer, I discussed how to detect when just the scroll bar was clicked on a draggable ListBox.  Today’s episode addresses something that happened to me on the other end: Dropping into the ListBox.

It probably makes sense that when a new item is dropped onto my ListBox, and therefore added to the list, I am setting the new item as the ListBox’s SelectedItem.  In theory, the ScrollViewer should automatically scroll the list so that the SelectedItem is in view.  In reality, this does not work (and I have it on good authority that it should.)  So in my scenario I am programmatically updating the SelectedItem, which now means I also need to programmatically instruct the ScrollViewer to scroll appropriately.

BringIntoView: The method that didn’t do anything

I want this code to run whenever the SelectionChanged event fires, so that is the method we will be using.  The first thing I tried was the BringIntoView method.  I tried it first on the ListBox itself, but realized that’s just silly since the ListBox is already in View.  What I really need is to tell the new SelectedItem to come into view.  If you have never done this, you may be surprised to find that you cannot cast the ListBox.SelectedItem object to a ListBoxItem: it is whatever type is DataBound to the List.  Instead, what I needed was a reference to the ListBoxItem that contains the SelectedItem.

In order to get the reference we need, we have to use the ListBox’s ItemContainerGenerator property.  This property exposes an ItemContainerGenerator object whose documentation is notably sparse.  But pull the object up in Intellisense and you’ll find a couple of useful methods, specifically ContainerFromItem and ContainerFromIndex.  We can use either one of these to retrieve a reference to the ListBoxItem container we need.  The code looks like this:

ListBoxItem item = (ListBoxItem)(ImageListBox.ItemContainerGenerator.ContainerFromItem(myListBox.SelectedItem));

Now that we have a reference to the ListBoxItem container, we can call its BringIntoView() method.

if (item != null)
{
    item.BringIntoView();
}

Unfortunately this was to no avail as it did not have the desired effect.  In fact, as far as I can tell, it had no effect, but it probably caused the ListBox’s RequestBringIntoView event to fire.  So, on to the next trial.

ScrollIntoView: The method that (almost) worked

Not to be thwarted, I began thumbing through Intellisense and found that ListBox has a method called ScrollIntoView.  For some strange reason, this sounded like it might be helpful, so I figured I’d give it a whirl.

ScrollIntoView (which is a really hard name to read in certain fonts because of the two lowercase ‘l’s followed by an uppercase ‘I’) requires that you pass it the object you want to scroll to, so we’ll pass it the ListBox.SelectedItem object:

myListBox.ScrollIntoView(myListBox.SelectedItem);

Now, if you run the code at first you will be lulled into a false sense of security.  This is the worst kind of bug, because it appears to work.  Change the SelectedItem and the ScrollViewer will adjust as necessary to scroll to the newly selected item… the first time.  What I found in subsequent drops to my ListBox was a very ugly bug.  It appears that the ScrollIntoView method gets caught in some kind of infinite loop, constantly resetting itself and causing the control display to gyrate wildly.  A little searching led me to this bug report at Microsoft.

This does not explain the exact same scenario, but it does exhibit the exact same results: an endless loop caused by a call to ListBox.ScrollIntoView(). Unfortunately, the bug is over a year old with no update or new information since it was accepted by Microsoft.

ScrollToHorizontalOffset: The method that does work

I was feeling pretty daunted at this point, but I decided to check one more thing before I quit for the day.  If I could get a reference to the ScrollViewer object itself, perhaps I could manually move it to the desired location.  I posted the code yesterday that I can use to retrieve the object reference, so all I had to do at this point was figure out what my options were for manually scrolling.

I found it in the ScrollToHorizontalOffset() method.  The method takes a double, which I mistakenly assumed was the number of screen units I wanted to scroll to, so I was trying to do a lot of math like measuring the ListBoxItem and multiplying the index number by the ActualWidth, and other pocket protector-y stuff like that.  Needless to say my first efforts were unrewarding.  I finally stumbled onto the fact the the HorizontalOffset indicates the index number of the item to scroll to – I was making it way too hard!  So all I had to do was pass the Selectedndex to the method and viola, a Scroll is born:

private void myListBox_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (myListBox.SelectedIndex >= 0)
    {
                ScrollViewer scroll = myListBox.GetScrollViewer();
                double scrollPos = myListBox.SelectedIndex;
                scroll.ScrollToHorizontalOffset(scrollPos);
    }
}

Conclusion

I’m far from done with my drag and drop reorderable ListBox, but I’ve learned a lot about the VisualTree, item containers, and obviously the ScrollViewer. This code is certainly not set in stone: if you know another way to do this or have any recommendations for the above code, please share them below in the comments.

In my current project, I have a horizontal ListBox wrapped in a ScrollViewer.  As you might expect, this indicates that I intend to have more content than my ListBox can display at any given time.  I am also implementing Drag and Drop reordering on this same ListBox.  This seemingly average task has turned out to be anything but, and I have spent the last couple of days fighting many issues, a couple of which are ScrollViewer specific.

Dragging and the scroll bar

The first problem I ran into was in initiating the Drag on the ListBox when the scrollbar was visible.  The problem is that the ScrollViewer is part of the default ListBox template, and the PreviewMouseLeftButtonDown event is wired to the ListBox.  This meant that if I tried to use the scroll bar, PreviewMouseLeftButtonDown would interpret it as a drag attempt and react accordingly.

In order to solve this, I needed to gain access to the ScrollViewer object that was part of the ListBox template, but there is no property for such an animal because the ListBox is completely unaware of the ScrollViewer.  And I could not access it directly because the ScrollViewer is not a named object within the Window, but rather it is part of the template.  So what’s a WPF developer to do?  The answer lies in navigating the VisualTree.

Navigating the VisualTree

In the code above, our XAML hierarchy ends at the ListBox:

Window
    LayoutRoot
        StackPanel
            ListBox

But the ScrollViewer lives inside the template definition of the ListBox.  So to access it at run time,we need to use the static VisualTreeHelper class.  To do that, we need to know what the template contains.  I used Blend to open a copy of the default ListBox Template which shows us the following hierarchy:

Template
    Border
        ScrollViewer
            ItemsPresenter

What we see is that the default ListBox template consists of a Border that holds a ScrollViewer that holds an ItemsPresenter.  This is important to visualize, because the ScrollViewer object we want is two levels into our ListBox, so we have to dig a little to get to it.  Our shovel for that digging is the VisualTreeHelper.GetChild() method.  I found this code posted by Matt Hohn at MSDN forums:

private ScrollViewer FindScroll()
{
    Border scroll_border = VisualTreeHelper.GetChild(PhotosListBox, 0) as Border;
    if (scroll_border is Border)
    {
        ScrollViewer scroll = scroll_border.Child as ScrollViewer;
        if (scroll is ScrollViewer)
        {
            return scroll;
        }
        else
        {
            return null;
        }
    }
    else
    {
        return null;
    }
}

In this code, Matt is using GetChild() to get the Border out of the Template.  The second time he uses the Child property to get the ScrollViewer from the Border.  I ended up moving this to an Extension Method so I could reuse it easily:

public static ScrollViewer GetScrollViewer(this ListBox listBox)
{
    Border scroll_border = VisualTreeHelper.GetChild(listBox, 0) as Border;
    if (scroll_border is Border)
    {
        ScrollViewer scroll = scroll_border.Child as ScrollViewer;
        if (scroll is ScrollViewer)
        {
            return scroll;
        }
        else
        {
            return null;
        }
    }
    else
    {
        return null;
    }
}

As you will see later, we will also need access to the ItemsPresenter within the ScrollViewer, so another simple Extension Method will do the trick:

public static ItemsPresenter GetItemsPresenter(this ListBox listBox)
{
    ScrollViewer scroll_viewer = listBox.GetScrollViewer();
    if (scroll_viewer is ScrollViewer)
    {
        ItemsPresenter list = scroll_viewer.Content as ItemsPresenter;
        if (list is ItemsPresenter)
        {
            return list;
        }
        else
        {
            return null;
        }
    }
    else
    {
        return null;
    }
}

Meanwhile, back at the Drag event…

So now that we can get a reference to the ScrollViewer, we have to determine whether or not the user is trying to scroll or drag an item within our ListBox.  To do this, we are going to start working in the ListBox_PreviewMouseLeftButtonDown event.  Remember that this event applies to the entire ListBox, so it will fire when the Scroll bar OR the ItemsPresenter are clicked.  To figure this out, we are going to check IsMouseOver to try to determine if the user clicked on the scroll bar or the actual items.  This gets a little interesting because the template hierarchy, and the inherent bubbling that occurs, means that when you click on the ItemsPresenter, both it AND the ScrollViewer will report IsMouseOver as true.  But if only the ScrollViewer is hovered over, then ItemsPresenter.IsMouseOver will report as false.

So we need references to both, and if ScrollViewer.IsMouseOver is true, but ItemsPresenter.IsMouseOver is false, then we can assume the user clicked on the scroll bar:

private bool IsScrolling { get; set; }
private void ImageListBox_PreviewMouseLeftButtonDown(object sender, MouseButtonEventArgs e)
{
    IsScrolling = false;

    ScrollViewer scroll = ImageListBox.GetScrollViewer();
    ItemsPresenter presenter = ImageListBox.GetItemsPresenter();
    if (presenter != null && scroll != null)
    {
        IsScrolling = (scroll.IsMouseOver && !presenter.IsMouseOver);
    }
}

We are storing the IsScrolling variable outside our method, because we are going to use it in the ListBox_PreviewMouseMove event to determine whether we are Scrolling or Dragging:

private void ImageListBox_PreviewMouseMove(object sender, MouseEventArgs e)
{
    if (e.LeftButton == MouseButtonState.Pressed && !IsDragging && !IsScrolling)
    {
        // Initiate drag code
    }
}

Enough fun for now

In my next post, I will discuss how to force the ScrollViewer to scroll to my SelectedItem when it is programmatically selected.