Controls that belong to 'Dirty' properties

[Chicagoan2016]

Hi,
I have a Csla 4.xx application, part of which is in Winforms.
We inform users if they try to close a form with dirty properties.
Is there a way we could highlight the controls that correspond to dirty properties?

Kind Regards

[hurcane]

There is nothing built into Csla for this. I have a general suggestion for one way to approach this need.

The base Csla classes do not track dirty per property. You could subclass BusinessBase and implement your own change tracking via overrides of PropartyHasChanged, OnPropertyChanging, LoadPropertyMarkDirty, MarkOld, and IsSelfDirty. If you want to track changed values on the server (useful for audit logging) and the change tracking fields are unmanaged, you will want overrides of OnGetChildren and OnSetChildren.

This is the approach our company has taken, but I am not allowed to disclose more details.

Once the business object has a method to query for which properties are dirty, you'll need UI code to connect the control to its bound property. My company does this within custom controls, but a helper class could probably be designed to work with a form and handle the dirty property checks and update the controls.

[hurcane]

A dirty property may not necessarily be broken. If the property value changed, but did not break a rule, there is nothing within the field manager nor the broken rules collection to identify that the specific property has changed.

[rockfordlhotka]

That's true, my mind went to broken rules for some reason.

The per property dirty tracking has come up many times over the years. It is an expensive thing to address, and the hooks are there for people to address it if they are willing to pay the price.

Basically, create a custom field manager that maintains a copy of the original property value, and returns isdirty based on comparison with the original value.

This doubles the size of the serialized payload.

[hurcane]

We had a brief discussion in San Diego last summer about this topic of tracking field-level changes. Yes, the custom field manager was inefficient. The methods that I listed are what my employer needed to override to keep an independent dictionary of original property values. The dictionary is only populated in modify mode as properties are changing (to add the original value to the dictionary) and after a property has changed (to possibly remove the original value (i.e. A -> B -> A). IsSelfDirty uses the dictionary count (>0 = true). MarkOld clears out the dictionary. Since the dictionary only contains data that has been actively changed for an existing object, the memory overhead is only affected by how many properties were changed. It's much more efficient that keeping a clone of the original object for comparisons, which was our original strategy.

LoadPropertyMarkDirty is an unusual scenario. It is called when a business rule affects other properties. In WinForms mode, affected properties don't raise the PropertyHasChanged event, so we had to include the dirty property evaluation within that method as well.

We also found that we needed to access the property in FieldManager and call MarkClean when the property was reverted to the original value because IsDirty becoming true in BusinessBase is a one-way operation until MarkClean is called. MarkClean at the property level is only applied with object-level operations, such as within MarkOld and when setting or merging state.

[rockfordlhotka]

I think you should be able to override IsSelfDirty to scan the FieldManager instead of using a simple value?

[Chicagoan2016]

A quick Google search shows Angular has that ability. We don't use Angular and I have never even looked at Angular 😂