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
|
In a previous thread, I asked about displaying different error severities via IDataErrorInfo. The approach that Ivan suggested has worked very well, but I'm hitting a new snag. For single objects, the error border displays as expected. But when I select multiple objects to be displayed in the grid (via MultipleObjectWrapper), the border does not appear. Interestingly, I do see the debugger hitting my multibinding converter so I know the binding is triggered. However, the style change in Validation.ErrorTemplate never appears. I've pasted an example of the style I'm using below. I've been wondering if, in the multiobject case, Validation.ErrorTemplate shouldn't be used or if there's a different editor key I need to be using. Any thoughts on what may be going wrong would be very helpful. Thanks, -Craig <ms:BuiltInEditorStyle |
|
|
In the multiobject case, the editor used is always the ManyEditor. But when the property value is consistent across the objects, the ManyEditor hosts an instance of the "normal" editor. My guess is that either: (a) somehow the text box is not managing to display its error template because of being contained in the ManyEditor; or (b) although the Validation.ErrorTemplate is being set on the text box, the text box binding does not think it is in error (and therefore the error template does not need to be displayed) because the binding is actually to a Many, and the Many is not propagating the error. Possible workarounds that I can think of are: 1. Style the ManyEditor as well as the SimpleTextEditor. If guess (b) is correct though this may not help. 2. Have your trigger make some error indicator visible rather than just setting the error template. Let me know if you need me to look further into this -- sorry I'm not able to give you a more detailed response right now but things are a bit rushed here at the moment! |
|
|
I looked at workaround 1 but I don't see how to style the ManyEditor as a TextEditor without WPF complaining that the TextEditor may not be appropriate. I assume I need to trigger of the IsConsistent property, but is there some other property I can also check to determine that a Text style is appropriate? For workaround 2, I first tried changing the setter property from Validation.ErrorTemplate to the textbox's border. From what I can tell, there was no impact. I suspect the error template was still catching the error in the single bound case and replacing my border changes with its own (since I did see the built in error border appear). In the multibound case, the border change didn't appear. I also tried setting the textbox's background to red, to filter any potential issues with the validation border. In the single bound case, the red background appeared as expected. In the multibound case, however, the background didn't change. I did some more debugging and I think I discovered the underlying problem. I'm using a multibinding to fire my converter, which checks the appropriate property's IDataErrorInfo value and returns a string that indicates the error's severity. DataTriggers check the value of the string, to display the appropriate error template. However, in the multibound case, UnderlyingObject comes in as Mindscape.WpfPropertyGrid.Many<> instead of the object type I really want to check. Since I can't cast it to IDataErrorInfo, I return an empty string so no trigger is fired. Additionally, the PropertyName comes in as "Value" so I won't know which property to check. Interestingly, if I multiselect and then edit a consistent property, the propertyName comes in with the actual property name and the proper object set. However, the converter is fired additional times after that with the seemingly bogus values. I also tried returning "Error" from the converter when the type can't be cast to IDataErrorInfo. In this case, the red background worked but the validation template didn't. I'm guessing that the fix is here is two-fold: 1. Alter the many editor's style (not just the text editor style) 2. Change the multibinding in the many editor so the right data is processed in the converter. Does the above add-up? |
|
|
Yep, that adds up, though it is a bit discouraging in terms of solving the problem. We can't implement IDataErrorInfo on Many or Many<T> because we don't know at compile time whether the aggregated objects implement IDataErrorInfo. (Worse still, in a heterogeneous selection, some objects might implement IDataErrorInfo and some might not!) However, I think we can add a property to Many which reports the name of the property that it is aggregating, which would enable your multibinding, if it received a Many, to call back to your IDataErrorInfo implementation on the aggregated objects. I guess we would also need to expose the set of aggregated objects so that the multibinding could be self-contained and not need to consult grid.SelectedObjects. Let us know if you would like us to do this. You are correct about triggering on the IsConsistent property, but rather than checking that a text style is appropriate, you can just have the consistent view display the correct editor by delegating back to the hosting grid's EditorSelector: <ContentControl Name="ConsistentView" (DeManyfier is a ManyToNodeConverter.) Let me know if you want me to post more detail of the starter template for ManyEditor, though I think this is the only subtle bit. |
|