Business rule question

ajj3085 posted on Thursday, June 01, 2006

HI all,

I'm sure others have come up against this, so I'd like to hear how you've handled it.

I have a business object, which has two integer properties (for the sake of keeping this question simple).  I have a business rule which dicates that those two property may never be equal.

The property settings look like this:

public int MyInt1 {
    set {
         if ( value != myInt1 ) {
                  myInt1 = value;
                  PropertyHasChanged( "MyInt1" );
                  ValidationRules.CheckRules( "MyInt2" );
         }
}

public int MyInt2 {
    set {
         if ( value != myInt2 ) {
                  myInt2 = value;
                  PropertyHasChanged( "MyInt2" );
                  ValidationRules.CheckRules( "MyInt1" );
         }
}


So if you set MyInt1 = MyInt2, there are two broken rules recorded, one for each property, stating that MyInt1 cannot equal MyInt2.  That works.

The problem is that when you set MyInt1 = MyInt2, the UI (ErrorProvider for MyInt2) doesn't notice
 that MyInt2 now is invalid.  I'm assuming this is because there was not a PropertyChanged event raised for MyInt2.  I know I can solve it by calling UnknownPropertyChanged, which would raise events for all the properties, but is that the best way to handle something like this?

For my BO, it shouldn't matter too much, there are only 3 properties total, but if I need to do this for a larger BO, there may be alot of PropertyChanged events raised which can hammer the UI.  It also seems odd to raise a PropertyChanged for a property which hasn't changed.

Andy

RockfordLhotka replied on Thursday, June 01, 2006

Your problem is that you have to call CheckRules before calling PropertyHasChanged. The ErrorProvider actually refreshes everything, but it does it on the PropertyChanged event - since you are checking the rules after that event has been raised, the ErrorProvider doesn't see the broken rule.

ajj3085 replied on Thursday, June 01, 2006

Ahh, of course, that makes sense.

Thanks
Andy