Problem with how OnPropertyChanged fires for WinForms app vs Xamarin app

[GreatBarrier86]

I've run into a problem with OnPropertyChanged. In WinForms, it appears OnPropertyChanged only fires for the property that is actually changing even though BusinessRules are run for any of the dependencies. In XAML, OnPropertyChanged fires for the dependencies as well. I do know this relates to the ApplicationContext.PropertyChangedMode property.

Because of this, I'm running into inconsistent behavior between our WinForms app and XAML app. Certain methods are getting called in OnPropertyChanged that we only expect to get called when that property value actually changes and not when it's "Changed" as a dependency, like the attached image. I tried setting PropertyChangedMode to Windows for the XAML app, but certain validation isn't being shown in the UI like it is when set to XAML

Do you have a suggestion on how to handle this?

[hurcane]

I don't think there is an ideal solution to this discrepancy. You can change the Winforms configuration to behave like the WPF app and raise an event for every property that was changed. The downside to this is a potential performance issue because Winforms databinding reads every bound property when a single property changes.

We have chosen to live with the performance hit, which is not usually noticeable. When it is noticeable due to a property that is somewhat complex to evaluate, we add an internal field to store a "cached" result, often using a nullable value. On any property change that could affect the cached result, we clear the cached field and the first property get will calculate it, but subsequent property gets will just return the cached result.

[rockfordlhotka]

The only way to truly resolve this, I think, would be to create a whole new property changed infrastructure that has nothing to do with data binding, and to raise these new events on a per-property basis for every change.

Windows Forms (and potentially Blazor) refresh all bindings for every PropertyChanged event, which is why CSLA has the mode that minimizes those events - trying to raise just one event for a whole batch of changes to minimize UI refresh churn.

WPF/UWP/Xamarin only refresh bindings on a per-property basis, based on the property name provided by each PropertyChanged event. In that case CSLA has the mode that raises one event for each property that changes.

[GreatBarrier86]

I'm trying to understand what you're saying. It seems to me that for XAML, if we change Property X, and there is a dependency between Property X and Property Y, OnPropertyChanged will fire for BOTH even if Property Y doesn't actually fire. Am i correct in that assumption? Inversely, in WinForms, it will only fire for Property X.

[rockfordlhotka]

We (you and I) don't control INotifyPropertyChanged - this interface is defined by Microsoft for data binding.

CSLA implements this interface specifically for the purpose of supporting data binding, nothing else. Any other use of the PropertyChanged event "isn't supported" - or at least it is only supported if you live within the boundaries of what data binding expects.

Unfortunately Microsoft hasn't been consistent with their use of PropertyChanged events.

• Windows Forms refreshes the entire UI (all bindings) for every PropertyChanged event it receives.
• The way I've been using Blazor also triggers an entire UI refresh of bindings for every PropertyChanged event.
• WPF, UWP, and Xamarin are the opposite, where they refresh only the binding for the property name specified in the PropertyChanged event.

CSLA has a PropertyChangedMode configuration setting that toggles between working for Windows Forms or WPF.

If you are building a WPF/UWP/Xamarin app you must use that mode, or your UI won't refresh correctly. In that mode lots of PropertyChanged events are raised, because we need one for each changed property. If you use this mode in Windows Forms it will work, but the UI will refresh all the data bindings a lot, which can be inefficient or even cause UI flicker on large data entry forms.

If you are building a Windows Forms app you can use either mode - but again, there's a cost to using the WPF mode because that's not how Windows Forms is designed.

[GreatBarrier86]

Sorry I'm behind, but I'm trying to understand. Basically you're raising it for the dependent properties because XAML's IPropertyChanged implementation isn't doing it, right? I'm not implying there is an issue. Just trying to understand why you're doing what you're doing.

It sounds like from a design-perspective (.NET-wise, not you), there is not a great way to handle this situation when the business objects are used for both WinForms and XAML. It seems that the "best" option would be to use XAML mode for WinForms and perhaps implement something like @hurcane suggested.

[rockfordlhotka]

Close 😀

Microsoft implemented data binding differently in XAML from Windows Forms. In XAML, they require a PropertyChanged event for every property that changes, because they only refresh one binding based on the property name provided via the PropertyChanged event. In Windows Forms they (imo) did it wrong, and they refresh all bindings for every PropertyChanged event, ignoring the property name provided by the event.

So back in the early 2000's, before XAML, I implemented CSLA to minimize the number of PropertyChanged events that were raised, trying to only raise one event for a whole batch of property changes. This made Windows Forms work well.

Then in 2005-2006 (??) when WPF came out I had to figure out how to make CSLA work with WPF (which wants one PropertyChanged event for each changed property) without crippling performance of Windows Forms apps, which refresh the entire UI for each event. To solve this, the PropertyChangedMode configuration switch was added to CSLA, and it defaults to the right setting depending on whether your app is Windows Forms or WPF.

If you use the PropertyChanged event for something other than data binding, then you need to understand all these gory details, because yes, the behavior of how the event is raised is different between Windows Forms (and now Blazor) and XAML-based UI's.

You absolutely can always use the XAML mode (override the default PropertyChangedMode when necessary), keeping in mind that there might be performance or flickering issues in Windows Forms/Blazor UIs.

[GreatBarrier86]

So let me ask this. What is the proper reason to overriding BusinessBase.OnPropertyChanged? In a PERFECT world, would it be used to call functions to set other properties. Imagine a scenario where setting OnPropertyChanged for Property X calls a calculation function that sets a value for Property Y. Should that be done there? Or should that calculation set be done in in a BusinessRule using Context.AddOutValue?

Based on your comment that "If you use the PropertyChanged event for something other than data binding, then you need to understand all these gory details, because yes, the behavior of how the event is raised is different between Windows Forms (and now Blazor) and XAML-based UI's", it sounds like doing a calculation in OnPropertyChanged would be a bad idea.

[rockfordlhotka]

Ideally all business rules are implemented as business rules. Thanks to @jonnybee, the rules engine is quite robust and should meet most needs.

[GreatBarrier86]

Then what would be the idea use of OnPropertyChanged on the BO side? Just trying to learn how it should be used.

[rockfordlhotka]

In any ideal world you'd never use it.

[hurcane]

I concur with Rocky. We have projects using Csla 3 and Csla 5. In Csla 3, we commonly used PropertyHasChanged() or OnPropertyChanged() and also event handlers within the business objects that handled the PropertyChanged event from INotifyPropertyChanged.

With Csla 5, we have always been able to process internal side effects using business rules and overriding OnChildChanged when child object changes need to trigger a rule evaluation in a parent class..

[GreatBarrier86]

@hurcane, just so i'm clear, if you had to do a calculation routine to set Property Y when Property X changes, you would use context.AddOutValue? Or would you set Property Y directly using Context.Target.PropertyY = CalculatedValue?

[hurcane]

We always use AddOutValue. We never change properties through context.Target.

[GreatBarrier86]

Does AddOutValue cause OnPropertyChanged to fire for it after the value changes or not? Is that what using AffectedProperties is for?

For some context, when we upgraded from CSLA 3 to 5, we didn't fully accommodate the new design necessary for setting properties in business rules.

[hurcane]

OnPropertyChanged behaves according the PropertyChangedMode setting. When using Winforms mode, only one PropertyChanged event is raised. Otherwise, all changed properties will raise a PropertyChanged event.

The business rule execution engine and the OnChildChanged method do not care about the PropertyChangedMode.

If you upgraded but did not completely rewrite your business rules, that's going to cause complications. We chose to go with a hybrid model. We forked the Csla 3 project to create a Csla3.dll with a Csla3 namespace and changed all of our legacy business projects to reference the Csla3 namespace. All new work is being done using the new paradigm with business rules.

[GreatBarrier86]

I understand that. I was wondering if AddOutValue bypassed notifying property changed. It sounds like it does not.

[pszittyay]

I have the same situation on a WinForms app where we changed a property on a BO using a BusinessRule and the AddOutValue method to set the new value. The value is changed but PropertyChanged does not, so the UI does not gets notified. I am surely missing something but i cannot figure out what
To make my self clear i had to add the following code after running de rule

 protected override void OnChildChanged(ChildChangedEventArgs e)
        {
            base.OnChildChanged(e);
            BusinessRules.CheckRules(AProperty);
---The X Property gets its value from a BusinessRule that its applied to the AProperty wich uses the context.AddOutValue to set XPorperty
---but i have to add the following to cause the UI to get notified
            OnPropertyChanged(XProperty);
        }

[rockfordlhotka]

@GreatBarrier86 iirc, you need to have added the output property(ies) to the AffectedList in the rule's constructor for events to be raised.

[GreatBarrier86]

@rockfordlhotka , which rule should it be added to? the rule for Property X or the rule for Property Y?

And doesn't adding dependencies automatically add to affected properties, or is that not correct?

[rockfordlhotka]

@pszittyay the BusinessRules.CheckRules method isn't running inside the business object, and so it can't raise the events. As I noted, what we might consider is adding a CheckRules method to BusinessBase, which then would be running inside the business object, and so could raise the events.

[rockfordlhotka]

@GreatBarrier86 I'd have to look at the code (or you could), but iirc, the list of affected properties in a rule only automatically gets the PrimaryProperty, and all others are provided by the author of the rule.

[Chicagoan2016]

• One of those rules calls AddOutValue(PropertyYProperty, newValue)
• The rules for Property Y which verify that its new value is valid does not get called again

As far as I could understand, you need to call the 'Validation' rules for Property Y from the rules you mentioned in Step 2.
I would look into rule chaining.