Migration to CSLA v8.x on a LOB mixing winform and wpf windows.

[GillesBer]

I'm assuming my LOB is non standard, and I'm facing an issue when trying to upgrade to CSLA v8.
Before, I was - at runtime - toggeling the PropertyChangedMode between Windows↔Xaml.
I relied on my WPF-window focus (Activated/Deactivated) to toggle to Xaml or back to Windows.

I understand that CSLA 8 makes the mode fixed for the process — that runtime toggle can no longer take effect.
Instead, it is only possible to configure it during startup using CslaConfig.SetPropertyChangedMode .

Is my understanding correct?
Any advice/best practice to overcome it when upgrading to CSLA v8.2.9?
Obviously, migrating all my Wpf to Winform (or vice versa) would be too huge !

[hurcane]

YMMV, but we set the mode to Xaml and live with the slight performance penalty on the Winforms UI. In our case, we actually need the Xaml mode because we have a lot of Winforms classes that have custom code that responds to specific property changes, no matter what action triggered that property to change. Xaml mode supports that easily. If we used Windows mode, the form would need multiple event handles based on the side effects from business rules. This is implementation leaking, which we prefer to avoid.

[rockfordlhotka]

I take it that you have an app that is hosting winforms pages in WPF, or WPF pages in winforms?

The mode is now managed by the ApplicationContext instance that is provided via dependency injection to objects and services that require it.

https://github.com/MarimerLLC/csla/blob/main/Source/Csla/Configuration/Fluent/BindingOptions.cs

The property in the options class is read-write. Unfortunately, it is later cached in the actual ApplicationContext code, and so isn't mutable after app startup.

I think @hurcane has the right answer. Or a fork, for your use, of CSLA to remove the caching code from ApplicationContext.

[GillesBer]

My LOB app is initialized as Winform, with some WPF windows.
As a workaround (to ensure I got the other migration issue to v8 surfacing), I had overridden my models that are used in my WPF windows as follow to use/force a custom PropertyChangedModes in a specific class.
This is not very clean, and I will check your suggestions.
Thanks

		/// <summary>To be overriden by classes that want to force Xaml (instead of the default Winform taken from the ApplicationContext)</summary>
		protected virtual ApplicationContext.PropertyChangedModes ForcedPropertyChangedMode
		{
			get { return ApplicationContext.PropertyChangedMode; }
		}

Forked from BusinessBase.cs implemented in my base business objects, replacing ApplicationContext.PropertyChangedMode by ForcedPropertyChangedMode

		/// <summary>Raises OnPropertyChanged for meta properties (IsXYZ) when the mode is not Windows.</summary>
		protected override void MetaPropertyHasChanged(string name)
		{
			if (ForcedPropertyChangedMode != ApplicationContext.PropertyChangedModes.Windows)
				OnMetaPropertyChanged(name);
		}

		/// <summary>Checks rules for the property and notifies the UI of properties that may have changed.</summary>
		[EditorBrowsable(EditorBrowsableState.Advanced)]
		protected override void CheckPropertyRules(IPropertyInfo property)
		{
			var propertyNames = BusinessRules.CheckRules(property);
			if (ForcedPropertyChangedMode == ApplicationContext.PropertyChangedModes.Windows)
				OnPropertyChanged(property);
			else
				foreach (var name in propertyNames)
					OnPropertyChanged(name);
		}

		/// <summary>Checks object rules and notifies the UI of properties that may have changed.</summary>
		protected override void CheckObjectRules()
		{
			var propertyNames = BusinessRules.CheckObjectRules();
			if (ForcedPropertyChangedMode == ApplicationContext.PropertyChangedModes.Windows)
				OnUnknownPropertyChanged();
			else
				foreach (var name in propertyNames)
					OnPropertyChanged(name);
		}