Suitability of Mindscape PropertyGrid

Greetings,

We're porting a VB6 application with a property grid to .NET and we're checking various WinForms and WPF alternatives. We'd like you to help us understand if your product fullfills our requirements.

We need to be able to fully customize the properties that appear and we need to do some preprocessing before the commit of the values is done, which can only happen when the user starts editing another property or presses enter or when the property grid looses focus. We need to always catch that event before any button click or similar event is raised on another part of the application (most controls we tested so far have problems here). We also need to have expandable property groups, editable combo-boxes, editors for multiline strings and for some cases we need to edit two properties on the same row, replacing the left colum which usually has the property name with an editable combobox. Additionally, we have some flag enum properties that need to be edited as a group of checkboxes, and as the filling of some combo-boxes needs a little processing we'd like to be able to fill them lazily only when the user presses the dropdown button. Here are a some rough screenshots of what we need:

Best Regards,
Gustavo Guerra
OutSystems

Hello Gustavo,

Thanks for considering us and for the detailed information about your needs.  I'll address your requirements one by one.

fully customize the properties that appear: You can remove properties by using BrowsableAttribute or a filter predicate.  If you need to add properties, you will need to implement ICustomTypeDescriptor.  Alternatively, instead of using an object and properties, you can use a dictionary, and the grid will display (and allow editing of) the contents of that dictionary as if they were properties, or you can manually add nodes using procedural code.

we need to do some preprocessing before the commit of the values is done: Depending on the nature of the preprocessing, you might be able to do this by creating custom editors that used an IValueConverter, and perform the preprocessing in the value converter.  Could you give an example of the kind of preprocessing you are thinking of?

We need to always catch that event before any button click or similar event is raised on another part of the application: In our (simple) testing this appears to be the case if the preprocessing is done in IValueConverter.ConvertBack.  WPF runs the value converter, then calls the property setter, then raises the Click event of the button.  If you are concerned about other events or other controls we'd advise explicitly testing those.

expandable property groups: Are you thinking of something similar to categories in the WinForms property grid here?  These are supported and you can also do custom grouping: see http://www.mindscape.co.nz/blog/index.php/2008/01/27/sorting-and-grouping-in-the-wpf-property-grid/.

editable combo-boxes: Supported.

editors for multiline strings: Not built in, but should be possible to add as a custom editor: see http://www.mindscape.co.nz/blog/index.php/2008/01/24/custom-property-editors-in-the-wpf-property-grid/.

for some cases we need to edit two properties on the same row, replacing the left colum which usually has the property name with an editable combobox: This is not supported.  It would probably be possible to do with some ingenious custom templating, but I suspect it would be quite difficult.

flag enum properties that need to be edited as a group of checkboxes: Not built in, but should be possible to add as a custom editor.

as the filling of some combo-boxes needs a little processing we'd like to be able to fill them lazily only when the user presses the dropdown button: This should be possible, but again would need a custom editor.  An interesting possibility here would be to use an asynchronous binding to create the combo box entries so that WPF could automatically run it in the background, avoiding a delay for the user when they pressed the drop-down button.

Regarding your screenshots, we do not currently support balloon tips on individual entries, and the default template always shows the editor controls in the right hand column  (e.g. in your Permissions group we would show Anonymous [ ] rather than [ ] Anonymous).  The default template can be overridden (I would encourage you do download the trial from http://www.mindscape.co.nz/Products/WpfPropertyGrid/download.aspx and check out the "Dialogesque" sample, or see the screenshot at http://www.mindscape.co.nz/blog/index.php/2008/01/29/taking-the-grid-out-of-the-wpf-property-grid/), but this has the potential to become complex if you have very specific UI requirements.

Thanks again for your interest and please let us know if you have any more questions. 

Regarding custom properties and preprocessing, we currently have a an interface IPropertyDescriptor that has getter and a setter methods, the human name, the description, etc..., and our objects have a method that returns an IEnumerable<IPropertyDescriptor>. We're currently using DevExpress in WinForms, and we're creating all the properties manually. We'd like to continue to use a similar scheme.

The tooltips are really a must have for us. They don't only appear when the text doesn't fit the column (like in the screenshot), but also when we need to provide more detailed descriptions of the porperty being edited. In our old VB6 implementation (using SmartUI), we've also gone to great lengths to make them appear even on disabled rows, so that is really important to us. Wouldn't it be possible to do with custom editors?

Having comboboxes on the left is a should have and we can live without them, but we rather not, could you provide any assitance on implementing this?

Do you have any public roadmap so we can know what's coming in your future versions?

Best Regards,
Gustavo Guerra

It sounds like it might be possible to implement your current scheme by using PropertyGrid.ItemsSource.  This expects an IDictionary rather than an IEnumerable, but I would expect it to be reasonably easy to create an IEnumerable<IPropertyDescriptor>-to-IDictionary<string, object> adapter.  The limitation here is that this would not give you custom attributes such as Description, Category, etc.  You could simulate this using smart dictionary keys (http://www.mindscape.co.nz/forums/Thread.aspx?ThreadID=1198) though (bundling your IPropertyDescriptor into the key).  An alternative approach would be to implement ICustomTypeDescriptor on your objects and have a canned implementation that delegates all the work to your existing IEnumerable<IPropertyDescriptor>.  Finally, the Enterprise edition of the grid includes full source code so it would probably not be too difficult for you to add a custom ItemsSource-like property that accepts IEnumerable<IPropertyDescriptor> directly (though obviously modifying the source has the potential to create maintenance/upgrade issues).

Custom editors would allow you to put tooltips on the editors, but not on the captions (the left hand column).  You could, however, get tooltips by retemplating the grid so that you could inject your own CellTemplate into the left hand column.  This isn't as intimidating as it sounds and there are examples in the download and in some of the blog entries and forum threads.

Retemplating would also be the first step towards meeting your combobox requirement.  The exact implementation would depend rather on your data model.  For example if you implemented the "combo group" as a single property of a collection type then that could probably be done using CellTemplateSelectors, but if the group consists of n individual properties tied together by metadata (e.g. attributes) then something extra would have to be done to prevent the grid from automatically displaying a row for every property.  We could certainly provide advice and support on this.

I'm afraid we don't have a public roadmap; we currently have a demand-driven approach to product enhancements as we find that feedback from customers is the best indication of what can be improved upon.  If we get a request for something that we believe would help other customers then we usually add it quite quickly (the current nightly build contains quite a lot of enhancements over the 1.0 version).  We do have plans, but we prefer not to comment on major enhancements until we're certain that we'll be delivering on them.

Regards,
Ivan