Custom Editor Adorments

Is there a way to add custom adorments to editors?  I'd like something similar to the 'x' that appears on a collection elment's editor, but not for a collection.  Effectivly I'd like a button placed to the right of a property's default editor that would allow me reset the property.  We could do this with a right click menu but need something more obvious.

My first thought would be to do a variation of a smart editor, but I'm wondering if there's a better way.  Thanks!

At the moment, a smart editor is probably the best way to do this, though it may be a bit tricky to hand back to the grid to select the "contained" editor without repeating a lot of logic.

However, the property grid infrastructure for 'editor decorations' was designed to eventually support user extension, we just haven't got around to building the user-extensibility bits yet because nobody has asked for them.  So this seems like the ideal opportunity!  If we were to provide you with an API for 'doing what the collection element decorator does' in a nightly build, would you be willing to beta test it and provide feedback?

The duplication of functionality was my biggest concerns about the smart editor approach.

I'd be happy to test & provide feedback on some exposed capability.  Do you have an idea of when these bits might be availible to test?

[quote user="MikeC"]Do you have an idea of when these bits might be availible to test?[/quote]

Around 1200 GMT!  It will be in the next nightly build.

What I've done is add a new EditorDecorations collection to the property grid control.  This is a list of "editors that can be wrapped around other editors."  Similar to a smart editor, you'll need to create an EditorDecoration class to represent the "what nodes does this apply to" logic, then provide an instance of it to hook it up to the DataTemplate which represents the wrapper.  Here's a simple example.

Creating the EditorDecoration class

Derive a class from TemplateEditorDecoration and override the AppliesTo method.  (You can derive from the EditorDecoration base class, but TemplateEditorDecoration takes care of the plumbing for the normal "and here's my DataTemplate" case.)  My example is going to decorate all properties whose names begin with "F".

  public class TrivialDecoration : TemplateEditorDecoration
  {
    public override bool AppliesTo(Node node)
    {
      return node.Name.StartsWith("F");
    }
  }

Creating the DataTemplate for the decoration

The DataTemplate can be pretty much anything you want, but it does need to host the actual editor, or there's not much point.  To do this, host a ContentControl whose Content is the ambient data context, and whose ContentTemplate is the DecoratedTemplate property of the containing EditorDecorator control.  You'll presumably also want to include a control that does something with the edited node, or again there's not much point.  You can get at this via the DecoratedNode property of the containing EditorDecorator control.  Here I'm just going to add a button which the user can press to display the name of the node.

    <ms:MarginInversionConverter x:Key="MarginInversionConverter" />

    <DataTemplate x:Key="NameInfoDecorator">
      <DockPanel Margin="{Binding DefaultMargin, RelativeSource={RelativeSource AncestorType=ms:PropertyGrid}}">
        <Button DockPanel.Dock="Right"
                Tag="{Binding DecoratedNode, RelativeSource={RelativeSource AncestorType=ms:EditorDecorator}}"
                Click="NameInfoButton_Click"
                Content="X"
                />
        <ContentControl Content="{Binding}"
                        ContentTemplate="{Binding DecoratedTemplate, RelativeSource={RelativeSource AncestorType=ms:EditorDecorator}}"
                        Margin="{Binding DefaultMargin, RelativeSource={RelativeSource AncestorType=ms:PropertyGrid}, Converter={StaticResource MarginInversionConverter}}"
                        />
      </DockPanel>
    </DataTemplate>

    private void NameInfoButton_Click(object sender, RoutedEventArgs e)
    {
      Node node = (Node)(((Button)sender).Tag);
      MessageBox.Show(node.Name + " is in hot pink");
    }

(I know using Click and Tag instead of Command and CommandParameter is ugly, but the point is just to illustrate how to get a binding for the node at hand.)

Note also the various margin incantations.  The property grid does some rather messy stuff with margins and these incantations keep things in the correct boundaries.

Hooking the template up to the selection logic

Now you can easily hook up the template to the 'starts with F' logic using the new EditorDecorations collection:

<ms:PropertyGrid.EditorDecorations>
  <local:TrivialDecoration DecoratorTemplate="{StaticResource NameInfoDecorator}" />
</ms:PropertyGrid.EditorDecorations>

Let us know if you run into any problems or have any feedback!

 Finally got a chance to try this out, it seems to be working very well.  Thanks!

I do have a couple questions:

1) In the button click event handler for the decorator, I'm dynamically modifying the underlying object, is there a good way to do targeted refreshes on portions of the grid?  Using PropertyGrid.Refresh() seems a bit too desctructive.

 2) I would my decorator to be little more dynamic, i.e. if the value changes I would like to reevaluate the visibility/enabled on the decorator (or at lease any visible UI in it).  I tried setting up a MultiValueConverter bound to the Node.Value property on the row, but this didn't update as expected:

<Button.IsEnabled>

	<MultiBinding Converter="{StaticResource PropertyCanResetConverter}" >

		<BindingPath="Node.Value" />

		<Binding Path="DecoratedNode" RelativeSource="{RelativeSourceAncestorType=ms:EditorDecorator}" />
 
	</MultiBinding>
 </Button.IsEnabled>
  

1. No, there isn't a way to forcibly refresh only part of the grid.  However, the grid should update itself in response to PropertyChanged events.  You might be able to get away with raising a "fake" PropertyChanged event for the property that you want to see refreshed.

2. Unfortunately, Node.Value does not raise property change notifications.  (It should have been a method rather than a property.)  If you are in an object wrapping scenario, you should be able to use {Binding Value} instead, as this should raise change notifications, and therefore cause the binding to be updated as the value changes.  Another option might be to hook the button to a Command, and put the logic in the command's CanExecute.  You would then be able to force a re-evaluation by calling CommandManager.InvalidateRequerySuggested.

Glad to hear it is otherwise working for you though!

The refresh was my bad, this was an edge case in our data model that didn't raise the PropertyChanged event.

And making the action a command worked perfectly; thanks again for exposing this!