Comments on: Editing custom types in the WPF Property Grid

By: Mindscape - MindBlog

Mindscape - MindBlog — Thu, 24 Jan 2008 19:48:41 +0000

[...] wrote previously about editing custom types in the WPF Property Grid—how to extend the grid to provide a good editing experience for, [...]

By: JD’s Blog » Mindscape ships the WPF Property Grid

JD’s Blog » Mindscape ships the WPF Property Grid — Thu, 24 Jan 2008 06:21:38 +0000

[...] has posted a a blog article about using custom editors with the Mindscape WPF Property Grid – I’d urge anyone interested in it to download the trial and then check out his article. Pass [...]

By: Alex Henderson

Alex Henderson — Thu, 24 Jan 2008 01:18:04 +0000

Not an immediate issue for me – was just wondering how that would be accomodated – being able to add the editors at run time would be more then enough to let me roll my own specific solution I would think :)

By: Ivan Towlson

Ivan Towlson — Wed, 23 Jan 2008 23:22:49 +0000

There’s nothing built into the grid that inspects a type or property for an editor declaration; at the moment, it is left entirely up to the hosting application to figure out what editors to hook up. But the application can certainly add editors at runtime from code. This would go something like:

TypeEditor editor = new TypeEditor();
editor.EditedType = myType;
editor.EditorTemplate = GetEditorTemplate(myType);
myGrid.Editors.Add(editor);

Here I am assuming that the application has defined a GetEditorTemplate method which returns a suitable DataTemplate. This might be implemented by inspecting an attribute on the custom type a la EditorAttribute, or by a naming convention, a configuration file mapping types to resources, or whatever. Similarly, it might load the DataTemplate from embedded resources in the add-in DLL, from a resource in the hosting application, from a satellite DLL, or wherever.

Note that this does depend on the application having some way at runtime of getting the relevant types so it can hook them up. If you know in advance which properties are going to have runtime-determined types, this is easy enough: just do a GetType() on the relevant values (and then go off and inspect their attributes or whatever). But if the edited object has a complex, deeply nested structure, and/or you don’t know at compile time which properties may have runtime-determined types, it could become tedious. This use case wasn’t on our list for v1, and offhand I don’t think v1 provides any workaround easier than walking the graph yourself, but it sounds like a good candidate for the wishlist. Let me know if this is an immediate issue for you.

By: Alex Henderson

Alex Henderson — Wed, 23 Jan 2008 22:26:40 +0000

What we would be the approach to dealing with this in a non-markup manor i.e. I have add-ins loaded at run time, which have their own strongly typed configuration classes and custom types – is there an equivalent to say the way WinForms does it with UITypeEditor, something that could be done with code attributes and embedded resources?

Looking great by the way :) very impressed.