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
|
Cliffs Notes Version: How can a CollectionElement get access to the instance properties and attributes of it's underlying (parent) Collection from within a Node/Editor? Full Version: Scenario: I have a property type which represents a filename. I have created: a) A custom Attribute defining the valid extensions etc. [AttributeUsage(AttributeTargets.Property)]
public abstract class MyDrivenEditor<T> : ObjectWrappingEditor c) A DataTemplate and Editors hookup for the custom editor which displays a button to fire a file selection dialog etc. <ms: PropertyGrid.Editors> d) Attribute entries on my objects. [FilenameAttribute(/*MyParametersGoHere*/)] [FilenameAttribute(/*MyParametersGoHere*/)] I cannot for the life of me get the elements of my collection to use the smart editor I've created. For a single property it's fine, but from a CollectionElement the Collection's property isn't visible. Furthermore, I can't work out (other than creating a custom type and using ms:TypeEditor(s)) how do get it to do so. Any ideas?
|
|
|
I don't think this is possible with the design you have in the current version of the grid, but it can be done with a tweaked version of the design. Suppose you were to change this: [Filename] to this: [Filename] public FilenameCollection AListOfFiles { get; set; } i.e. create a vacuous subclass of ObservableCollection<string> whose sole job is to carry the attribute. Then your CanEdit implementation could check if the node were a collection element and if so look to the type of the containing collection: public override bool CanEdit(Node node) The reason for needing a type to carry the attribute is that node.Source is the *value* of the collection property (e.g. the value of AListOfFiles), not the property metadata. And the only place we can hang metadata off a value is via its type. Is this an acceptable workaround for you? I know it could result in a proliferation of do-nothing subclasses if used to excess, but if you've not got too many of these attributes then it might be okay. If not let me know and I will see what we can do (no promises though!). |
|
|
I guess the problem there is really that we're now applying the attribute to the class, not the property, so I'd need a class for every possible permutation of attribute parameters. That might potentially be achievable using generics, except that I'm really simplifying the situation a lot and the properties in question are actually dynamically generated using a custom property descriptor. Is there a fundamental design reason why nodes don't actually know what their parents are? I've hit that twice now (trying to draw tree heirarchy lines, and this).
|
|
|
No, there's no fundamental design reason, and to prove it, a new Node.Parent property will be in tonight's nightly (9 July, available from about 1430 GMT). Please note this may not be set under all circumstances (top level, manually added nodes, etc.). So please do check it, and let us know if you run into any cases where you think it ought to be set but it isn't. I have tested it in the "collection elements wanting to know their parent at CanEdit time" so it should suffice for your immediate requirements -- again, let us know if it doesn't or if you run into bugs or issues. |
|
|
I <3 Mindscape. |
|