Add/Remove items in sub property collections

I have a list<> property in an object that initially starts with no items in it. It displays in the default property grid with 0items as the value, with a small + in a circle to the right of it.

 How do I go about enabling the ability to add items to the collection?

 I just realized it was adding them when I click the plus button, it just wasn't updating the property grid.

 Sorry if this sounds silly, but what actually happens when you click the + button? Does it just call the default constructor for the object it's a collection of? If so is there a way to control which constructor is called? Or even pass parameters to the constructor?

If you change your List<> to ObservableCollection<> (or something else that implements INotifyCollectionChanged) then the grid will update automatically when things are added to the collection (whether using the + button or from your own code).

Regarding object construction: yes, it just calls the default constructor.  There is no direct way to override this, but you can interpose your own command binding for the CollectionAddCommand:

pg.CommandBindings.Insert(0, new CommandBinding(PropertyGrid.CollectionAddCommand, OnCollectionAdd));

In your handler, e.Parameter is the collection that is being added to, so your handler will look something like this:

private void OnCollectionAdd(object sender, ExecutedRoutedEventArgs e)
{
  ObservableCollection<Fie> collection = (ObservableCollection<Fie>)(e.Parameter);
  collection.Add(CreateAnObjectHoweverYouLike());
}

Note you must use Insert so that your binding takes precedence over the built-in one, and that by doing this you get stuck with responsibility for handling all collection adds, which may be a pain if you have several child collections and only one of them needs special handling.  (Call CollectionUtilities.AddDefaultValueEntry(collection) to fall back on the default behaviour.)  If this is a significant issue for you then let us know your scenario and we'll see what we can come up with.

 Thanks Ivan, I'll have a play around with your suggestion. I'm not sure if we want to have to handle all collection adds though, but I'll experiment.

I'm not sure it's a significant issue yet, we're still playing around with exactly how the interface for our app will function. A prior version of our product had customized dialogs for editing almost all object properties, we're giving the property grid a shot this time around just to see if it simplifies things. Whether or not it simplifies things depends mainly on these complex scenarios, we just have to figure out if the way it works is intuitive enough for the user.

 Could you do a kind of hack whereby you create a dummy collection similarly named, then whenever a new item is added display a dialog to get extended information from the user? Or what about just adding buttons that do other things to the property grid... If you could do that I could put an 'add widget' type button on that could then prompt the user for what is required then call whatever constructor etc is necessary..

You can actually do this pretty easily using the standard editor extensibility mechanisms and a bit of No. 8 wire.

Let's suppose that you have a class Grocklet which has a custom constructor or factory method or whatever, so you need to provide special treatment for adding to ObservableCollections of Grocklets.  We can do this in four steps:

1. Create a DataTemplate to replace the default "collection header" (the "x item(s)" and the + button).  This will look something like this (note this will actually produce a dead ugly UI but it should give you the idea):

<DataTemplate x:Key="GrockletCollectionHeader">
  <DockPanel>
    <TextBlock DockPanel.Dock="Left" Text="{Binding Count}" />
    <Button DockPanel.Dock="Right" Tag="{Binding}" Click="AddGrocklet_Click">Add</Button>
    <TextBlock Text="item(s)" />
  </DockPanel>
</DataTemplate>

Note that instead of having the button invoke the standard CollectionAddCommand, we're having it call our own Click handler.  (You could make it invoke a custom command, which would be more elegant, but would complicate the example.  The way of passing the collection to the Click handler is also frankly a kludge -- again done for brevity.)

2. Write the Click handler:

private void AddGrocklet_Click(object sender, RoutedEventArgs e)
{
  ObservableCollection<Grocklet> gs = (ObservableCollection<Grocklet>)(((Button)sender).Tag);
  gs.Add(BringMeAGrockletFromSomewhere());
}

3. We need to hook up the custom editor template to the ObservableCollection<Grocklet> type via the normal TypeEditor mechanism.  But there's a problem.  XAML doesn't give us a way to talk about generic types (except in specific circumstances that don't help us here).  This is where the No. 8 wire comes in.  We will create a XAML markup extension that adds generic types to the XAML language.  To keep things simple, we won't try to make this completely general, we'll just do the one generic type we're interested in, ObservableCollection<T>:

public class ObservableCollectionOfExtension : MarkupExtension
{
  private Type _elementType;

  public ObservableCollectionOfExtension(Type elementType)
  {
    _elementType = elementType;
  }

  public override object ProvideValue(IServiceProvider serviceProvider)
  {
    return typeof(ObservableCollection<>).MakeGenericType(_elementType);
  }
}

4. With this markup extension in hand, we can now write the TypeEditor declaration for the property grid to use our custom template (and custom button and custom Add logic) for any ObservableCollection<Grocklet> it comes across:

<ms:PropertyGrid.Editors>
  <ms:TypeEditor EditedType="{local:ObservableCollectionOf {x:Type local:Grocklet}}"
                 EditorTemplate="{StaticResource GrockletCollectionHeader}"
                 AllowExpand="True"
                 />
</ms:PropertyGrid.Editors>

Notice the use of the markup extension in the EditedType property, and the AllowExpand="True" which tells the grid to still display the child items even though there's an editor defined.

That's all you need to do.  And you can extend the DataTemplate as you wish, for example if you wanted both a "Quick Add" button that generated default values and an "Add Wizard" that interacted with the user to get the initial values.

What if the type isn't fine enough granularity for you.  Perhaps your object has two ObservableCollection<Bird> properties, and you want to run different Add logic -- different Bird constructors or factory methods -- depending on whether the user is adding to the Mallards or Penguins collection.  In this case you just change the TypeEditor to a PropertyEditor:

<ms:PropertyGrid.Editors>
  <ms:PropertyEditor PropertyName="Mallards" DeclaringType="..."
                     EditorTemplate="{StaticResource MallardCollectionHeader}"
                     AllowExpand="True"
                     />
  <ms:PropertyEditor PropertyName="Penguins" DeclaringType="..."
                     EditorTemplate="{StaticResource PenguinCollectionHeader}"
                     AllowExpand="True"
                     />
</ms:PropertyGrid.Editors>

In this case you don't need the ObservableCollectionOf markup extension, but your DataTemplate needs to change slightly:

  <DockPanel>
    <TextBlock DockPanel.Dock="Left" Text="{Binding Value.Count}" />
    <Button DockPanel.Dock="Right" Tag="{Binding Value}" Click="AddGrocklet_Click">Add</Button>
    <TextBlock Text="item(s)" />
  </DockPanel>

You now need to reference the collection via the Value pseudo-property instead of it being the implicit data context.

Hope this makes sense.  You mentioned you were fairly new to WPF so things like markup extensions may be a bit unfamiliar to you but do feel free to ask for clarification if it's not clear what's going on here.