I get the need for that middle ground sometimes. Like Command
s that need 3 values from CanExecute
rather than true
or false
.
As for warnings that operate like validation, I don't know all the pieces one would need to put together, but I think I know how one would start.
You would need to rely on attached properties and attached behaviors (attached properties that subscribe to events on the object and perform operations related to those events when they fire). You might have one that governs a collection of ValidationRule
objects to use to determine whether a warning is issued or not, much like the Validation
properties do. You might have one called HasWarning
that gets set or unset by the validation that can be referred to in style/template triggers.
You could make the warning display part of each control's template, or you could again mimic Validation
and have a WarningTemplate
attached property that is used to place the warning information in an AdornerLayer
.
Since custom ValidationRule
objects return a ValidationResult
object in which the ErrorContent
is simply an object, and this object is also exposed in the ValidationError
objects as ErrorContent
, you may also be able to use the regular validation after all. You could possibly use a class as your ErrorContent
object that has an ErrorType
property of Warning or Error and bind to that in your ErrorTemplate
.
I'm not sure whether having ValidationError
s present would prevent certain operations (such as button presses) you would wish to allow, but some sort of proxy on the ViewModel could be created that judges the ErrorType
.