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
|
Hi, I'm sure I am doing something wrong here because it's hard to believe the property grid doesn't handle this case propertly. Given the following test case: public interface ITest ... propertyGrid.SelectedObject = new The property grid displays the List with 4 items as expandable, but then it displays each of the Item elements with a ListSelectNoTextEntryEditorKey, and its AllowExpand set to false. This appears to be a bug in the property grid. The PassthroughPropertyInfoAdapter.Converter property gets a converter for the "PropertyType" and the ShouldUseStarndardValue in ReflectionUtilities that checks on this converter uses the dataType.IsInterface. The problem here is that PropertyType on the Item is ITest whereas dataType is the object's type , ie:Test - and dataType.IsInterface is false. Therefore, the converter that is being checked on is a ReferenceConverter (which returns true on get standardValuesSupported()) instead of a normal type conveter... This leads to the BuiltIn editor to jump in on that particular case and return the ListSelectNoTextEntryEditorKey. So, what am I doing wrong? What is the expected behavior of the above test? And how can I make the property grid behave such that the Items expand to show the name without having to hack the hell out of the property grid or the templates/styles etc? Thanks! Pablo |
|
|
This does seem to be a bug, but it is easy to work around by providing a TypeEditor for the interface type and setting AllowExpand = True: <DataTemplate x:Key="ITestSummary"> |
|
|
That is true and easy. Except that having a fairly large project and a pluggable architecture at that - there are going to be plenty of situations where the interface is just unknown - defined by the user... Meaning that the user needs to specify the editor themselves...
|
|
|
You could probably work around that using a smart editor where the test would be "is the node a collection element, and is it of interface type." The user would still need to remember to specify the smart editor, but the editor itself could be generic. (This is not to say we won't address the issue in the control -- just trying to offer a workaround until that happens!) |
|
|
I think that is a bit more palatable - I already have a proxy typeeditor to have runtime editor discovery so I can do the check there. |
|