Using ItemsSource to populate WPF ListBox - Good Idea?

Question

I'm a (relatively) experienced Cocoa/Objective-C coder, and am teaching myself C# and the WPF framework.

In Cocoa, when populating an NSTableView, it's relatively simply to assign a delegate and datasource to the view. Those delegate/datasource methods are then used to populate the table, and to determine its behavior.

I'm putting together a simple application that has a list of objects, lets call them Dog objects, that each have a public string name. This is the return value of Dog.ToString().

The objects will be displayed in a ListBox, and I would like to populate this view using a similar pattern to Cocoa's NSTableViewDataSource. It currently seems to be working using:

public partial class MainWindow : Window, IEnumerable<Dog>
    {
        public Pound pound = new Pound();

        public MainWindow()
        {
            InitializeComponent();

            Dog fido = new Dog();
            fido.name = "Fido";
            pound.AddDog(fido);

            listBox1.ItemsSource = this;

            Dog spot = new Dog();
            spot.name = "Spot";
            pound.AddDog(spot);
        }

        public IEnumerator<Dog> GetEnumerator()
        {
            return currentContext.subjects.GetEnumerator();
        }

        System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
        {
            return GetEnumerator();
        }
    }

But I'm wondering how correct this is. I've literally had Visual Studio installed for less than an hour, so it's safe to say I have no idea what I'm doing.

1. Is this the proper pattern?
2. Adding the second item to the list (spot) seems to update the ListBox properly, but I'm wondering what triggers the updates?
3. What happens if I update the Pound on a background thread?
4. How can I manually ask the ListBox to update itself? (Do I even need to?)

One change that I know I need to make is refactoring the IEnumerable<Dog> implementation into its own class, like DogListItemsSource, but I want to make sure I have a solid approach before polishing it.

Feel free to point out, in comments, any other points I should address or keep in mind, big or small. I'd like to learn this the right way, the first time.

Solution 1

My suggestion would be to create a class besides your Window which would be responsible for providing the data to your ListBox. A common approach is WPF is called MVVM, which like any pattern has many implementations.

The basics are each Model (e.g. Pound and Dog) would have a View Model responsible for presenting the model in a manner which is easy to interact with from the UI.

To get you started, WPF provides an excellent class, ObservableCollection<T>, which is a collection that fires off a "Hey I Changed" event whenever anybody is added, moved, or removed.

Below is an example that doesn't intend to teach you MVVM, nor does it use any framework for MVVM. However, if you set some breakpoints and play with it, you'll learn about bindings, commands, INotifyPropertyChanged, and ObservableCollection; all of which play a large role in WPF application development.

Starting in the MainWindow, you can set your DataContext to a View Model:

public class MainWindow : Window
{
     // ...
     public MainWindow()
     {
         // Assigning to the DataContext is important
         // as all of the UIElement bindings inside the UI
         // will be a part of this hierarchy
         this.DataContext = new PoundViewModel();

         this.InitializeComponent();
     }
}

Where the PoundViewModel manages a collection of DogViewModel objects:

public class PoundViewModel
{
    // No WPF application is complete without at least 1 ObservableCollection
    public ObservableCollection<DogViewModel> Dogs
    {
        get;
        private set;
    }

    // Commands play a large role in WPF as a means of 
    // transmitting "actions" from UI elements
    public ICommand AddDogCommand
    {
        get;
        private set;
    }

    public PoundViewModel()
    {
        this.Dogs = new ObservableCollection<DogViewModel>();

        // The Command takes a string parameter which will be provided
        // by the UI. The first method is what happens when the command
        // is executed. The second method is what is queried to find out
        // if the command should be executed
        this.AddDogCommand = new DelegateCommand<string>(
            name => this.Dogs.Add(new DogViewModel { Name = name }),
            name => !String.IsNullOrWhitespace(name)
        );
    }
}

And in your XAML (be sure to map xmlns:local to allow XAML to use your View Models):

<!-- <Window ...
             xmlns:local="clr-namespace:YourNameSpace" -->
<!-- Binding the ItemsSource to Dogs, will use the Dogs property
  -- On your DataContext, which is currently a PoundViewModel
  -->
<ListBox x:Name="listBox1"
         ItemsSource="{Binding Dogs}">
    <ListBox.Resources>
        <DataTemplate DataType="{x:Type local:DogViewModel}">
            <Border BorderBrush="Black" BorderThickness="1" CornerRadius="5">
                <TextBox Text="{Binding Name}" />
            </Border>
        </DataTemplate>
    </ListBox.Resources>
</ListBox>
<GroupBox Header="New Dog">
    <StackPanel>
        <Label>Name:</Label>
        <TextBox x:Name="NewDog" />

        <!-- Commands are another big part of WPF -->
        <Button Content="Add"
                Command="{Binding AddDogCommand}"
                CommandParameter="{Binding Text, ElementName=NewDog}" />
    </StackPanel>
</GroupBox>

Of course, you'd need a DogViewModel:

public class DogViewModel : INotifyPropertyChanged
{
    private string name;
    public string Name
    {
        get { return this.name; }
        set
        {
            this.name = value;

            // Needed to alert WPF to a change in the data
            // which will then update the UI
            this.RaisePropertyChanged("Name");
        }
    }

    public event PropertyChangedHandler PropertyChanged;

    private void RaisePropertyChanged(string propertyName)
    {
        var handler = this.PropertyChanged;
        if (handler != null)
            handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

Finally you'll need an implementation of DelegateCommand<T>:

public class DelegateCommand<T> : ICommand
{
    private readonly Action<T> execute;
    private readonly Func<T, bool> canExecute;
    public event EventHandler CanExecuteChanged;

    public DelegateCommand(Action<T> execute, Func<T, bool> canExecute)
    {
        if (execute == null) throw new ArgumentNullException("execute");
        this.execute = execute;
        this.canExecute = canExecute;
    }

    public bool CanExecute(T parameter)
    {
        return this.canExecute != null && this.canExecute(parameter); 
    }

    bool ICommand.CanExecute(object parameter)
    {
        return this.CanExecute((T)parameter);
    }

    public void Execute(T parameter)
    {
        this.execute(parameter);
    }

    bool ICommand.Execute(object parameter)
    {
        return this.Execute((T)parameter);
    }
}

This answer by no means will have you whipping up immersive, fully bound WPF UI's, but hopefully it'll give you a feel for how the UI can interact with your code!

Solution 2

1. In WPF you usually just have some collection as ItemsSource and data templates to display the item.

2. Normally those controls only update if the ItemsSource instance implements INotifyCollectionChanged, maybe you added the item before the ListBox retrieved it.

3. What is Pound? Unless Pound has some thread-affinity as e.g. ObservableCollection does, that is no problem, if it does you need to use dispatching.

4. ListBox.Items.Refresh() could do that, but usually you just use a collection with notifications.

WPF heavily uses data binding, so if you want to learn the framework the respective overview (along with all the others) might be of interest.

Comments

[Craig Otis]

Yikes, this stuff is complicated! A far cry from the simplicity of KVO and MVC and IBOutlets, but perhaps I still need to warm up to it. :) Thank you very much for the explanation and tailored example, I'll be referring to it frequently over the next couple days.

[Sam]

@craig: Yeah it's different than Obj-C, that's for sure. Granted I have a hard time going from WPF to Obj-C/Cocoa ;) Useful links to MVVM frameworks: WPF Application Framework or Prism 4.0 and Prism's Chapter 5: Implementing the MVVM Pattern are both good places to start.