Developing For .NET

I learned something interesting about ListBox and scrolling content this week.  In hindsight it is obvious, but trust me: that’s the last thing you want to hear after two hours of beating your head on your keyboard trying to figure out why the stinking ListBox isn’t scrolling.  Read on for the gory details.

The Obvious

What I learned is this: if you have an Auto sized ListBox, meaning that it will stretch its Width and Height to match its contents, the ListBox will never produce a Scrollbar.  Even if the content stretches far off the window: in that case, it just so happens that the ListBox will also stretch far off the window.  Since the content is not larger than the ListBox itself, no Scroll bars.

Obvious, right?  Not so: I have recently had several frustrating experiences with the Auto settings for Width and Height.  Don’t get me wrong! I use them a lot, and I tell others to do the same because they greatly assist in laying out elements, especially in Grids.  The problem comes when they don’t do what I *think* they are going to do.  In the case of the ListBox, I was operating under the assumption that they would Stretch the ListBox to fit the available space in the container, and that is not how they behave.

The Solution

Realizing my error, I understand now that the scrolling behavior is controlled by the relationship of the size of the Content to the defined (as opposed to visible)size of the ListBox itself.  In my case, I had the ListBox as the last element of a StackPanel.  I needed the ListBox to fill the remaining space, and I needed the Content to scroll vertically. 

The Width of the ListBoxItems was set to the width of the ListBox, minus a little to allow for the Scrollbar, so that wasn’t an issue.  I wanted the Height to fill the remaining space, but I had no way to bind to the measurement and I wanted to avoid a lot of code behind hijinx.  As discussed above, setting it to Auto would actually prevent the desired behavior, so that option was out. 

In this particular case, the application is a fixed size, so I was able to set the size of the ListBox manually to fill the remaining space in the StackPanel, and lo and behold my Scrollbar appeared.  All was well, or so I thought…

The Case of the Changing StackPanel

In testing, we realized that the element above the ListBox (an Image control) should only be visible when it had an Image to show.  So naturally I wired up a ValueConverter and bound the Visibility to a boolean property in the ViewModel reflecting whether or not there was an Image to display.

This worked great for the Image, but an ugly thing occurred with the ListBox.  Since its Height was hardcoded, it shifted up in the StackPanel and no longer stretched to the bottom.  It look pretty strange just hanging there, Scrollbar happily in view, but a bunch of empty space beneath it.

спални комплекти

So just when I thought I had it licked, I’m back in the same boat with the same problem: I need my ListBox to automatically fill all the remaining space in the StackPanel.  Wait, what was that?  I want a child to fill all remaining space?  That sounds familiar…

Enter the DockPanel

Once I got back up from having the ton of bricks fall on my head, I realized that I was using the wrong container!  What I really needed in that scenario was a DockPanel.  I was just using StackPanel out of habit, I had no specific need for it, and the items within it would never be more than the Image and the ListBox.

So using Blend’s trusty “Change Layout Type” feature, I changed my StackPanel to a DockPanel.  I made sure the LastChildFill property was checked and docked the Image control to the Top and set the VerticalAlignment to Top.  I then did the same thing for the ListBox and set its Height property to Auto.  Running the application gave me exactly the result I was after in the first place: an automatically resizing ListBox restrained to it’s Parent container’s remaining available space.

Lesson Learned

So aside from learning a lesson about ListBox and scrolling, I also learned that I need to probably pay a little more attention to the container type I am using.  Grid and StackPanel have always been my defaults since they cover most scenarios, but I also need to remember we have other options.

I began working on our first major WPF project last December.  Previously I had done a lot of playing and learning, and written a few internal utilities, but this was our first release grade project.  Things were going well and the partners were very happy with the software development… that is until “the bug”.

The Back Story

The software is an image management tool that interfaces with our legacy AS/400 application.  In short, it allows images on a network server to be linked with data records in our legacy application.  It is a replacement for an existing application written in FoxPro, so you can imagine the Oohs and Ahhs at the new UI.  The project also fills in some serious deficiencies in functionality.

As one can probably surmise, one important piece of functionality when managing groups of images is the ability to add, remove, or rename images.  With File IO such a rudimentary function, I had let it lapse until the end of the project.  Since WPF was the focus of my development, I had lost focus on the project itself.  I spent a lot of time making the application sing with animations, transitions, Visual States, drag and drop with a Visual Brush, you name it I wanted to try it.

Near the end of February I began working with the final bits, which included deleting an Image and saving an updated list of images back to the server.  As soon as I tried to perform any such action on any image, however, I would receive an IOException: "The process cannot access the file because it is being used by another process."

I worked intermittently on the issue while I continued improving the UI.  I figured it had to be something simple, so it took a little while until I began devoting serious effort to solving the problem.

Working on the Problem

Since the project was winding down, I began working on the problem in earnest about the middle of March.  I was able to determine that it was my application causing the lock, so I did a little research and found plenty of indication that opening images has a tendency to lock the file until the application ends.  With the idea that my application was holding the resource I tried to find a way to close it out until the operation was complete.

Without all the gory details, here is a list of things I tried in varying degrees, all of which failed to solve my problem:

• Setting the ListBox.Source to null.
• Adding a wait time before attempting the move.
• Issuing GC.Collect().
• Moving the operation to a different thread.

All of these were to no avail.  Eventually I posted the problem to StackOverflow and received two responses in short order.  I tried both of the solutions, but neither one seemed to solve my problem.  I asked a few friends on Twitter and email, but no one was able to help beyond what I had already tried.  By the end of April I was ready to call it quits.

Unfortunately for the project, but fortunately for my sanity, other projects became more important.  This gave me an official hiatus from the project, but I would still return to it occasionally in my spare time, always with the same results and frustrations.

Early in July my hiatus was over: the total project (the image project is a subproject of a larger effort) deadline is set at September 1st.  Panic set in: I have three applications to deliver in that time, and one of them is the Image manager.  I put it off a little while while I wrote one of the other applications, but on July 18th I returned full time to my nemesis.  The good news was there was little left to do: the bad news was that I had already spent countless hours on one stupid bug that was make or break for the entire application.

The Solution

I had little choice but to start from the beginning.  I went back to the StackOverflow discussion because it seemed to hold the most promise.  I wrote a test application that just performed the action I wanted, deleting an Image that was in the application.  By using a combination of the two methods in that thread I was able to get the feature working.

The solution that worked was to create a Value Converter that accepted the path of an image and returned a BitmapImage. 

[ValueConversion(typeof(string), typeof(BitmapImage))]
public class PathToBitmapImage : IValueConverter
{
    public static BitmapImage ConvertToImage(string path)
    {
        if (!File.Exists(path))
            return null;

        BitmapImage bitmapImage = null;
        try
        {
            bitmapImage = new BitmapImage();
            bitmapImage.BeginInit();
            bitmapImage.StreamSource = new FileStream(path, FileMode.Open, FileAccess.Read);
            bitmapImage.CacheOption = BitmapCacheOption.OnLoad;
            bitmapImage.EndInit();
            bitmapImage.StreamSource.Dispose();
        }
        catch (IOException ioex)
        {
        }
        return bitmapImage;
    }

    #region IValueConverter Members

    public virtual object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        if (value == null || !(value is string))
            return null;

        var path = value as string;

        return ConvertToImage(path);
    }

    public virtual object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        throw new NotImplementedException();
    }

    #endregion
}

I then bound the Image source to the path of the image using the converter. While this image (or rather a local copy of the image) was on the screen, I was able to delete the file from the server.  I had tried a version of this previously, but I assumed it wasn’t working because I was still getting the error. Now I had proof that this code works.

Applying the Solution

I was able to apply the solution to the original application after some refactoring.  It’s amazing how much my coding style has changed from the last 6 months experience with WPF.  I look at the application now and cringe, especially at the code behind.  Anyway, I was able to shoe horn my solution in and the images showed correctly.  Can you imagine the anguish I felt, however, when the first time I tried to delete an image I received the same error?

I was quite dismayed, until I realized that it was not the actual image code since that had been proven: there had to be something else causing the problem, but what?  I had already gone through all the code and every reference to an image with a fine toothed comb, several times, what more could there be?  I began the process over again, but I was not a happy camper.

And then it dawned on me.  I finally knew what the problem was: I had been bitten by Data Binding.

How Can I Blame Data Binding?

To be fair, the issue is not with Data Binding per se, but my own misunderstanding of the object I was binding.  The images were bound not once, or twice, but three times:

• ImageListBox – each item is bound to a different image, effectively a FilmStrip control
• CurrentImage – a larger Image control showing the selected image from ImageListBox, bound to ImageListBox.SelectedItem
• DeleteImageDialogBox – a separate Window that displays the image and prompts the user to confirm deletion, the Image is bound to the path passed in from the parent Window

For both ImageListBox and DeleteImageDialogBox I had used the new Value Converter.  CurrentImage, however was a different story.

In binding CurrentImage to the SelectedItem property of the ListBox, I was expecting the property to represent the rendered image that was the result of the Value Converter.  This is completely wrong!  The SelectedItem property is still the file path string!  CurrentImage was still executing the default behavior and retrieving the file from the path resulting in a file lock.

The Resolution

Once I understood what CurrentImage was binding to, I knew what to do: apply the same Value Converter I was using for the list box items.  Sure enough, once I applied that Value Converter everything else fell in place.

In hindsight I feel this was an “Oh Duh” sort of problem.  So many times the solution to our most frustrating problems is right in front of us, and almost always the solution is fairly simple.  As I said to a friend recently – it’s amazing sometimes that we ever get anything right!

Now I have a new issue: via the Value Converter I’m going to the file system three times to show the same image.  I’ll have to address that at some point, and I have a few ideas.  I could store the BitmapImage copy, or a byte[], or a MemoryStream locally and reuse it.  For now, however, I’m going to leave well enough alone and get on to my next application.  Hopefully it won’t take six months to finish.

I’ve been a big fan of Value Converters in WPF for some time now, but I was bitten today by something simple and thought it would be worth sharing.

Brush Converter

One of my favorite uses for Value Converters is to set colors of things based on object state.  In my current application, I have drawn a circle that I want to be filled in Red if the application is not connected to the database, and green if it is connected.  My binding engine has an “IsDatabaseConnected” boolean property that I can use for the binding, so what I need to do is bind the bool to a Brush. To do this, we create a simple converter:

using System.Windows.Data;
using System.Drawing;

namespace CamraSketchViewerWPF
{
    public class DatabaseConnectedColorConverter : IValueConverter
    {
        public Brush ConnectedBrush { get; set; }
        public Brush NotConnectedBrush { get; set; }

        #region IValueConverter Members

        public object Convert(object value, System.Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            if (value is bool)
            {
                var isConnected = (bool) value;
                return isConnected ? ConnectedBrush : NotConnectedBrush;
            }

            return null;
        }

        public object ConvertBack(object value, System.Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            throw new System.NotImplementedException();
        }

        #endregion
    }
}

In the XAML we need an instance of the Converter to bind to: I used Blend 3 to write the XAML, but whether you do it this way or write it by hand you should end up with something like this:

<local:DatabaseConnectedColorConverter x:Key="DatabaseConnectedColorConverter" />
 

This will create an instance of the Converter as a resource that can then be used for the actual binding:

<Ellipse Fill="{Binding IsDatabaseConnected, Converter={StaticResource DatabaseConnectedColorConverter}, Mode=Default}" Width="15" Height="15"/>
 

If you run the code like so, you will get a transparent circle.  What’s missing are the property value declarations for the Converter. In addition to declaring the instance in XAML, we can also set its properties in XAML like so:

<local:DatabaseConnectedColorConverter x:Key="DatabaseConnectedColorConverter" ConnectedBrush="{StaticResource GreenBrush}" NotConnectedBrush="Red" />
 

Note that for ConnectedBrush I have defined my own version of Green as a resource. Now, if you run this code, you’ll receive the same exception that bit me:

‘Brush’ type does not have a public TypeConverter class.

It’s always the simplest things…

I have run into this message and others like it, and it is always frustrating.  What it means is that the Type I am trying to descibe in XAML does not have TypeConverter behavior defined: this is what allows simple Strings in XAML to be properly transcribed into correct types at runtime.

In this case, the problem was a simple one but not an evident one.  Now I love code completion and refactoring tools as much as the next guy, so whenever Intellisense volunteers to help me out I am quick to accept the assistance.  In this case, however, it did more harm than good!

When I referenced the Brush in my Value Converter class code, I was prompted by Intellisense to resolve the missing namespace, which I did with the handy-dandy Shift-Alt-F10 keystoke.  Only I did it reflexively and did not actually read my options.  If you look at the code above, you will see that the Value Converter class is referencing the System.Drawing namespace instead of the System.Windows.Media namespace.  System.Drawing.Brush was not written for WPF and so does not have the TypeConverter code necessary for this to work.  The problem is easily corrected by changing the namespace appropriately.

Conclusion

I placed this in the “Read your options” file for future use. If you are interested in more TypeConverter details, check out this article by Rob Relyea at XAMLfied.

So I’m sure this will be filed in the *yawn* category for you experienced WPF developers out there, but I ran into an interesting item on Friday that I wanted to share.  I was developing a custom DialogBox that displays a lot of text and an image from a CLR object passed in from the calling Window.  The text is fairly long, three short paragraphs, but includes several bits of variable data (properties on the CLR object).

I had several options for how to go about this:

1. Build the Text dynamically in the code behind.
2. Create several TextBlock items and string them together, probably using WrapPanel, and bind the variables to the CLR properties.
3. Store the desired text in the TextBlock.Text property with place holders and use it in a String.Format statement to insert the property values.  (I could have also stored this string in an external file)

I’m sure there are other options, but I didn’t want to spend a lot of time on this.  Option 1 just seemed too blunt, not to mention that I couldn’t see in Blend what it would look like from a design perspective.  Option 2 would probably work, and from a pure XAML approach would be preferable, but I was in a hurry so I went with what I knew (or so I thought) and chose option 3.

I immediately liked this idea because I could really see the end result in Blend.  To handle the variable embedding, I planned on reading in the TextBlock.Text value in the constructor and storing it in a private variable.  Then I could read the values passed in and reset the .Text property:

private string messageFormat ;
private DeleteImageDialogBox()
{
    this.InitializeComponent();
    messageFormat = MessageTextBlock.Text;
}

public DeleteImageDialogBox(PictureInfo pic, string archiveDirectory)
    : this()
{
    LayoutRoot.DataContext = pic;

    string message = String.Format(messageFormat,
        pic.GetRecordNumber(),
        pic.GetCardNumber(),
        archiveDirectory);

    MessageTextBlock.Text = message;
}

Unfortunately, this did not work.  A little debugging soon showed me why: TextBlock.Text was an empty string. This was confusing because Blend shows the Text property as containing my text.

Apparently, because I had CRLFs in my Text, the actual text was no longer exposed by the Text property, but was now part of the Inlines property.  Inlines is of type InlineCollection, a collection of Inline objects.  Inline objects are used to manage a line of content. Inline is an abstract class, so the actual collection can contain multiple types. In my case, I had to test for two types: LineBreak and Run.  In order to retain my formatting, if I detected a LineBreak I inserted “\r\n”.  If I detected a Run object, then I could grab the text.

So if you aren’t confused yet, or even if you are, here is the code I used to extract my full text into a usable string variable:

StringBuilder s = new StringBuilder();
foreach (var line in MessageTextBlock.Inlines)
{
    if (line is LineBreak)
    {
        s.Append("\r\n");
    }
    else if (line is Run)
    {
        Run text = (Run)line;
        s.Append(text.Text);
    }
}
messageFormat = s.ToString();

The only formatting I am retaining here are the LineBreaks: if my text had Underlines, Bolds, etc., I would need to add more code above to retain them.  This may seem like a lot of effort, but if I can definitely see the value for text formatting and processing.  I expect to see this again when I get deeper into WPF printing.

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.

In my current application, I have a ListBox that displays images horizontally.  Basically it is a WPF FilmStrip (without the control) with some additional features.  One feature is a toolbar that includes navigation buttons.  First and Last buttons are easy: they are always available and always navigate to the first or last image in the list.  The Previous and Next buttons are also easy to navigate, by simply incrementing or decrementing the SelectedIndex value of the ListBox.

Simple IValueConverter

While WPF seems to automatically handle numbers less than 0 and greater than the Items.Count, I only want the Previous and Next buttons enabled based on the SelectedIndex.  If the index is 0, I do not want the Previous button enabled, and if the index is the last one, I do not want the Next button enabled.  To accomplish this, I need to convert the SelectedIndex to a Boolean, so I wired up an IValueConverter.  In the case of Previous, it is a simple task in the converter to just compare the SelectedIndex to 0:

    public class SelectedItemIndexIsNotFirstToBoolean : IValueConverter
    {
        #region IValueConverter Members
        public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            if (value is int)
            {
                int index = (int)value;
                return (index > 0);
            }

            return false;
        }

        public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            throw new NotImplementedException();
        }

        #endregion
    }

Basically, the converter returns True if the value is > 0 so that IsEnabled will be True.  Now to wire this up, just add the Converter to the Binding:

The XAML above does several things: first, the Path is the Property name of the Element (specified by ElementName) we want to send to the Converter. The Converter is a reference to a Resource instance of the Converter, which means you’ll have to add a line for this in Window.Resources:

If you aren’t impressed yet, think about what just happened: I bound a boolean value of a control (it could be any of them, not just IsEnabled) to the SelectedIndex value of a ListBox with no code behind or events. I don’t include the Converter classes as code behind, because I can easily see working up a DLL full of these and using them in many applications.

MultiBinding using IMultiValueConverter

The Next button, however, was not as straight forward as the Previous button.  In this case, I needed to check the SelectedIndex against the Items.Count property to see if this is the last Image in the list.  At first, I tried to use RelativeSource binding to navigate the tree and send the ListBox itself, but I quit for two reasons.  The first reason is it got hairy in a hurry I couldn’t get it to work.  The second reason is that I could see using the resulting IValueConverter for other applications and Control types, so I didn’t want to limit it.  The answer therefore became finding a way to send both the SelectedIndex and the Items.Count to a IMultiValueConverter.

A IMultiValueConverter functions much like an IValueConverter, receives an object[] as the first parameter.  Then, like the IValueConverter, we can simply process the array values and use them to determine the return value:

public class SelectedItemIndexIsNotLastToBoolean : IMultiValueConverter
{
    #region IMultiValueConverter Members

    public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        if (values[0] is int && values[1] is int)
        {
            int index = (int)values[0];
            int count = (int)values[1];
            return (++index != count);
        }

        return false;
    }

    public object[] ConvertBack(object value, Type[] targetTypes, object parameter, System.Globalization.CultureInfo culture)
    {
        throw new NotImplementedException();
    }

    #endregion
}

As you can see, other than processing multiple values, there is very little difference between the two.  The question then becomes “how the heck do I wire this thing up?”  If you are using Blend, I have bad news: as far as I can tell there is no way to wire up MultiBinding in Blend.  The good news is that it was really easy to do in XAML and required no RelativeSource or anything funky like that:

I broke the IsEnabled property out of the button and added a MultiBinding tag to it that contains all the magic.  You have to specify the Binding tags in the order the IMultiValueConverter is expecting them.  The statement is very simple, referencing the ElementName and Path as above for each value to be passed to the Converter.  I did discover something interesting: look at the second one and you’ll see I indicated “Items.Count”.  I didn’t actually think this would work since I am referencing a subproperty, but the Count came through just fine. And of course, don’t forget to add a reference to the Converter to Window.Resources.

Conclusions

There is some concern out there that too much stuff will get shoved into XAML just because we can.  The question you have to ask yourself is whether or not the time invested and the result are worth it.  In this case, I think it is justified.  Most of the time I invested here was learning the technique, which is a cost I won’t have to pay again.  It also ended in much less coding in my button Click events, and is completely reusable for different scenarios and future projects.

The software I’ve been developing needs to be accessible from the command line, and in those cases it needs to be able to receive parameters in order to properly initialize the application instance.  I’d done this plenty of times in Windows Forms, but when I started looking for the public static void main entry method, I couldn’t find it.  It didn’t take long to find the answer, but I thought it was worth sharing.

Windows Forms

In Windows Forms, the way I’ve always done this is to add a string[] args parameter to Main(), which is found in “Program.cs”.  Then I override the Form constructor and pass the array to the Form.  You can also use Envorinment.GetCommandLineArgs().  That post had a couple of comments where the users seemed concerned because the first element of the array contains the full path to the executable.  If you choose this method, simply ignore index 0 and you can access the parms in exactly the same way.

WPF

The method in WPF is the same basic concept, but it occurs in a slightly different way.  Right off the bat, you’ll notice there is no “Program.cs” and no Main() method to process.  Instead, the entry for the application is found in “App.xaml.cs”.  There is no entry method here like Main: in order to process the incoming paramters, we need to add a listener to the App_Startup event.  This event will fire prior to the Window class being executed. In order to hook the event up to the application, edit “App.xaml” and add Startup=”App_Startup” to the Application declaration.

The event includes a StartupEventArgs object, which contains a reference to the Args array, so you would simply parse it as desired just like in the Windows Forms Main() method. The difference with WPF is that we do not have a call to the Window class exposed like we do in Windows Forms.  What we do have, in the Window class, is access to the Application object itself.  Microsoft’s sample, downloadable from MSDN, creates a static variable in the App class and populates it in the App_Startup event.  The Window class then accesses the static App variable for its access to the command line arguments.

The sample above parses the values and stores them in a Hashtable (yuck!), so obviously we have some better options, like a generic Dictionary.  Or even better, how about a custom class that holds the values you want?  This would be especially good if some of the values are not strings, or to enforce business rules on the incoming parameters.  I like this approach because it allows all the parsing work to be done outside the Window, leaving the Window to only determine how to use the results.  It just feels better to me since one of our primary goals with WPF is separating layers of responsibility.

If you don’t like the process above, or you really want to handle the parsing inside the Window class, you still have access to Environment.GetCommandLineArgs(), and it works exactly like it does in Windows.Forms.  Again, you can just ignore the 0 index and process the arguments directly.  Oh, and if you are a real glutton for punishment, both methods include the Environment.CommandLine property, a string that represents the complete command line entry.

Debugging Command Line Parameters

I hate trying to navigate through the DOS shell (excuse me: Command Prompt) to find the exe file of my project in order to test command line argurments.  Fortunately, we don’t have to!  If you go to the main menu and follow Projects -> “xxxApplication Properties”, and then click on the Debug tab, you’ll find a box where you can enter the Command Line Arguments you want to test.  As expected, they will be included when the application begins and you can debug their values.