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
|
I just discovered an interesting issue; the property grid doesn't multiple properties with the same name. This is the case with some of our dynamic data types; the properties are added to the collection returned form ICustomTypeDescriptor.GetProperties(). The property grid ignores the first property to occur. In this particular case I have a custom filter at the UI level, which would cause the second property to be ignored; but the first property is never passed into my delegate. So a quick short term solution might be to call the filter before building (what I presume is) the Dictionary<Node>. I did a quick check & the WinForm PropertyGrid handles the multiple properties. Let me know if there's any way for you guys to fix this. Thanks! |
|
|
Hmm, just to be clear, are you talking about: * multiple objects of different classes with the same-named property (SelectedObjects = { new Person(), new Darkness() } and both Person and Darkness have a Heart property); or * a single object which (by the magic of ICustomTypeDescriptor) has two properties with the same name? I think it's the latter case but just wanted to check before I investigate further. Does the object display incorrectly (only one property shown in UI) or is it just the filter which isn't receiving the duplicate properties? |
|
|
I'm referring to the second case: a single object which (by the magic of ICustomTypeDescriptor) has two properties with the same name? If I display the object with no filtering only a single property per name shows up; it's always the last property with that name in the PropertyDescriptorCollection. |
|
|
I can't reproduce this: I've got a test ICustomTypeDescriptor returning multiple properties with the same name, and they're showing up okay, and my filter method is being called for each one. (I've attached a screenshot to show what I'm seeing.) I have found an issue if you use SelectedObjects in this scenario (because SelectedObjects merges properties on name, even if there is only one object in the multi-select), but that's muddling up the values, not the actual presence of the property -- I still see two "bob" properties even in the multiselect scenario. Long shot, but is it possible that the missing property is a real property on the object (rather than a dynamic one) and you have not merged descriptors for the real properties into your PropertyDescriptorCollection? Failing that, is it possible for you to provide us with a small project that reproduces the problem? Thanks! |
|
|
Strange it works for you. I know the data I'm looking for is definitely a dynamic property. I set up a side-by-side comparison of the WinForm & the WPF property grid (see attachment). You can see the Entry & Environment Map properties are missing their duplicates. Scanning through the list I couldn't find any duplicates showing up in the WPF grid. One thing I can think of is we have a LOT of properties in this particular data by default; it's basically a property bag & can hold any of 17,000 properties. And yes all 17,000 are returned by ICustomTypeDescripter.GetProperties(). Also the PropertyDescriptors returned are the custom descriptors from my previous post on custom sorting. Another feature I found failing in this case is group by category. I don't know if it's related but when I tried to group it didn't work. All the properties with the same name are in different catagories, so I was curious if that would cause it to show up. I tried grouping by using the Grouping='{x:Static ms:PropertyGrouping.ByCategory}' XAML. Again the groups show up find in the WinForm grid. Any thoughts? |
|
|
Correction: 1700 properties, not 17,000. |
|
|
Ok, I've figured something out. I left out a criticle piece of information in my explanation. I am using PropertyGrid.SetObjects to set the object(s) I'm editing. Currently there is only one object in the array. (Note: Later I may be editing multiple objects with slightly different properties.) When I use PropertyGrid.SelectedObject, the categories & all the properties appear correctly. |
|
|
I can reproduce this if the multiple properties with the same name have different data types (e.g. one "bob" is an int and the other "bob" is a string). Can you confirm that this is the case for your duplicate properties? If not -- if your duplicate properties have the same data type -- I think you're going to need to provide us with a repro. If so, I have a fix for this but there's another issue with duplicate names in multiple select that I need to fix too -- I'll let you know when it's all done. |
|
|
Correct, the properties are different data types. |
|
|
Hello Mike, I have implemented a candidate fix for this and it will be included in nightly builds dated 14 Jan 2010 and above, available from about 1500 GMT. Please consider this an experimental fix for now. It is working in our test environment but it is clear that your scenario is significantly more complex than ours. Please let us know if you run into any issues, including details to reproduce them. One caveat: it looks like we still have issues if there are multiple properties with the same name and same data type. This seems to be a limitation with the underlying PropertyDescriptor and PropertyDescriptorCollection classes. If this is an issue for you then let us know and I will take a look, but I can't make any promises about a fix in this case. |
|
|
Just to add: I have not yet tested the grouping and filtering behaviour, as I wanted to get your feedback first on whether the main problem was solved or not before looking into that side of things. If these still aren't working, let me know. |
|
|
I could see the issue with same named & typed properties potentially coming up. But in our case we do have namespaces for these. If we overrode GetHashCode to take the namspace into account would that fix the problem if the issue did crop up? |
|