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 have created Property Editor for all my Wavelength classes <ms:TypeEditor EditedType='{x:Type c:Wavelength}' I am trying to ovveride Editor for some properties in code but it has no effect PropertyEditor editor = new PropertyEditor(); However if I remove (comment) <ms:TypeEditor ..../> in xaml, PropertyEditor defined in code applies properly. |
|
|
Is "SomeProperty" a Wavelength (as well as being declared *on* a Wavelength)? This would cause the issue you are seeing. The grid searches the list of editors in order they were added, and will find the Wavelength TypeEditor (added in XAML) before it finds the "SomeProperty" property editor (added in code). If this is the case then you will need to add the TypeEditor in code *after* adding the PropertyEditors, so that the TypeEditor has a lower priority. Otherwise, I haven't been able to reproduce the issue. Here is the code that I used to try to reproduce the problem. Am I doing something obviously different to you? Does this code work for you? You should see a yellow box for the "Fie" property... XAML: <Window.Resources> In the window code-behind (in the constructor): Wavelength wavelength = new Wavelength { Fie = "fie", Tchah = "tchah" }; And the model classes (where Observable is as defined in the WPF Property Grid samples): public class Widget : Observable
|
|
|
I attached small program which reproduce problem. I have class Class1 with two properties W1 and W2 of type Wavelength. I dont want expand the second property so I added editor for W2 in code. If you run program W2 still expanded but if I comment <ms:PropertyGrid.Editors> in xaml W2 wont be expanded
|
|
|
Okay, I now understand the situation. Your Class1 class has two properties of type Wavelength. You want one of them to get a special PropertyEditor specified in code, and the other one to get the default TypeEditor specified in the XAML. The reason this occurs is that we search for viable editors in the order they appear in the Editors collection -- we do not search the entire list of editors looking for "higher priority" or "more specific" ones. As soon as we find an editor that can edit the property at hand, we adopt it. In your case, because the TypeEditor was added first (implicitly through XAML), when we search for an editor for W2, the TypeEditor gets first dibs, and the search never reaches your PropertyEditor. So how do you get your PropertyEditor in ahead of the TypeEditor? Call grid.Editors.Insert rather than grid.Editors.Add, to insert the PropertyEditors at the *beginning* of the Editors collection rather than at the end. |
|
|
You right after I changed Editors.Add(editor) to Editors.Insert(0, editor) the second property becomed nonexpandable as should be. But there must be some easier way to make some properties of the same class nonexpandable rather than insert new editor based on the same template and setting editor.AllowExpand = false? |
|
|
[quote user="voronov"]But there must be some easier way to make some properties of the same class nonexpandable rather than insert new editor based on the same template and setting editor.AllowExpand = false?[/quote] As we originally conceived the editor system, the idea of a TypeEditor was to allow you to specify a way of editing custom types in place, with AllowExpand as way to access additional details or break out the type for easier editing: that is, we believed expandability would be part of the static definition of how the application author wanted to present Wavelengths, PhoneNumbers, etc. The use of TypeEditors to display non-editable summaries changes that a bit: AllowExpand is now acting as a read-write vs. read-only flag in a way, something that one wants to control on a property-by-property basis rather than at the type level. This means we probably need to revisit this area in order to support conditional expansion as you suggest. I have added it to our product backlog and we will look into it. |
|