This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
As far as I can tell, when AllowModifyCollections is set to true and the plus icon next to a collection-based property is clicked, the PropertyGrid attempts to construct a new instance of the type of object contained by the collection by invoking the default constructor of the type. Is it possible to override the construction behavior, either through a callback, event, or overriding a virtual method, such that an object factory is invoked instead of the default constructor? |
|
|
There's no direct way to do this, though it's something we'd be open to adding. As an indirect route, you can replace the content displayed against a collection row using a PropertyEditor, so that instead of showing our Add button and calling our Add behaviour, you can show a button that invokes your own Add behaviour. First, here's the editor declaration: <ms:PropertyEditor DeclaringType="{x:Type t:Person}" In your data template, you then provide a button which calls your factory and adds the result to the collection. In the DataTemplate, you can get at the collection by binding to the Value. <DataTemplate x:Key="MyAddOMatic"> (A proper implementation would use Command and CommandParamter but I'm keeping it quick and dirty here.) If you want to use the same add template for different kinds of collections or different factories, you can pass additional data down the template using the PropertyEditor.EditContext, which you can then retrieve as {Binding EditContext} and pass through to the click handler via an attached property or whatever. For example, your EditContext could be the particular factory to use. |
|
|
Thanks for the suggestion. I tried it out and it almost works. The problem is that when I use my template, the little "+" to the left of the collection row disappears. So, I'm able to add items to my collection, but I can no longer expand the row and edit or remove the items within the collection! Ideas? Thanks! |
|
|
Oops, sorry, forgot about that. You need to add AllowExpand="True" to the <ms:PropertyEditor ... /> element. (AllowExpand defaults to false because usually when you're providing an editor, you're handling subproperties yourself. Obviously, that's not the case here, so you need to explicitly re-enable the expand behaviour.) |
|
|
Hi Ivan, I wonder how to go about solving my issue, which is simillar to the one described above. I have a working custom template for editing my own ObservableDictionary and it works great with one exception - I cannot use the little (-) next to dictionary items to remove individual items from the ObservableDictionary. I did some testing and came to the conclusion that you are using reflection behind the scenes to perform element adding and removal but I wasn't able to figure out quickly enough how/where to overwrite this behavior for my scenario. I have an ObservableDictionary(Of String, Attachment) where Attachment is my own custom type. The reason I decided to use ObservableDictionary instead of using an ObservableCollection is that I wanted to overwrite the default "Item[x]" label coming up for each item. I would like it to read "Attachment x" instead. ("Attachment x" is going to be my string key :) ) The ObservableCollection(Of Attachment) still has this issue though. So I guess I have two questions: 1. Is it possible to overwrite the "Item[x]" label for a collection element? 2. How can I overwrite EditorTemplate for the elements in my ObservableCollection/ObservableDictionary? Regards, Kyryll
|
|
|
Just realised that ObservableCollection DOES work, so really I only need one of the above solutions from above :) |
|
|
Which one do you still need? Changing the label to "Attachment x"? |
|
|
That would be good :-) How can I do that? Thanks Ivan |
|
|
The only way to do this at the moment is to override PropertyNameTemplate, which can be a bit hairy because it means you have to handle EVERYTHING in the left column including non-collection items, expand buttons, etc. The good news is that 95% of this is boilerplate. Take a look at: http://www.mindscape.co.nz/forums/Post.aspx?ThreadID=1171&PostID=9002 It's not pretty, but honestly it's not quite as bad as it looks. Once you've got that in place you can plug in your own naming strategy using a good old value converter (you'll be particularly interested in CollectionElement.IndexedPropertyArguments) and you should be good to go. |
|
|
Ivan - in your first response to this message, you said Mindscape would be "open to adding" the ability to override the object creation behavior of the PropertyGrid when clicking the "+" for collections. Now that my team has licensed WPF Elements, would it be possible to get this change made? Ideally, the PropertyGrid class would just expose a protected virtual method that was something like: protected virtual object CreateObject(Type objectType) with a default implementation that just uses Activator (or whatever it currently does). Thoughts? Thanks! |
|
|
Sure, this will be in the next nightly build (available for download around 1200 GMT). Rather than make it a virtual method, I've made it an event, so that users don't need to subclass the control (it also makes it a bit easier to evolve). The event is named CollectionAddRequested: if you handle this event and set the event args Value property then the grid will use your value rather than the default: private void Grid_CollectionAddRequested(object sender, CollectionAddRequestedEventArgs e) In future I'd like to provide the property info for the collection property, so that you can distinguish between different properties of the same type (e.g. if a Person class has Friends and Relations collections, which you might want to default differently). This is a bit tricky at the moment though, and from your post it sounds like it's not needed for your current scenario, right? As always, let us know if you run into any problems! |
|