I'm using the StringLength attribute on a property to ensure the value never goes beyond a certain length. I've run into a strange scenario.
* The user types in data into a text box that is bound to the BO property. So far, so good.
* The user types in data that goes beyond the expected length. I see a red border show up in the text box - again, this is expected.
* Now, the user changes something on the screen that fires a rule that makes the property change to string.Empty. This is also working as expected.
* However...I still see the StringLength broken rule, even though I've confirmed that property getter is called and GetProperty is returning string.Empty.
I've got to be missing something obvious, but ... something doesn't seem right. Even though my rule sets the property to string.Empty via context.AddOutValue(), it seems like the BO has already decided that it's evaluated the StringLength rule and it still thinks it's broken.
Am I not using the attribute correctly? Any insight is appreciated - TIA.
Hi Jason,
Yes, I think you are using the attribute correctly.
Which Version of CSLA and UI?
Might be connected to the PropertyChangedMode (default WindowsForms in 3.x and earlier, Xaml in 4.x) that could cause UI and BO to loose sync.
Is the rule stilll broken in the BO?
If the rule that sets the field value to string.Empty is triggered from a "dependent" property than that may be the reason the field is not revaildated.
Well, I found a hack... :)
Since the rules run for data annotation-based rules run at priority 0, and we use a base class for all business rules, I just set the priority to -1 so our rules would run first. That seemed to fix it, and our all tests pass, but this does feel a little hackish.
Well, if the rule that sets the property to string.Empty runs after the DataAnnotation rule that would explain the behavior. 
Seems to. We've never set the Priority level before, so all the rules were at 0. It was just an ordering issue.
Copyright (c) Marimer LLC