RaiseListChangedEvents

JoeFallon1 posted on Monday, October 29, 2007

In all of my collections I use code like this during fetch:

RaiseListChangedEvents = False

'get the data

RaiseListChangedEvents = True

I have a case where I wanted to ensure that no events were raised but I can't seem to find where in the CSLA framework the code above is being "honored".

Specifically, this code does not honor the setting for RaiseListChangedEvents:

Private Sub Child_PropertyChanged(ByVal sender As Object, _ByVal e As System.ComponentModel.PropertyChangedEventArgs)
For index As Integer = 0 To Count - 1
    If ReferenceEquals(Me(index), sender) Then
      OnListChanged(New System.ComponentModel.ListChangedEventArgs( ComponentModel.ListChangedType.ItemChanged, index))
      Exit For
    End If
Next
End Sub

Even though I set it to False the code in Child_PropertyChanged still runs and raises OnListChanged.

This is causing a problem because the ObjectListView is subscribing to the event and is re-sorting itself "on the fly". This is bad because I am in a Web app and am trying to get the data in a grid into the corresponding BO in the collection. I have them all lined up and am ready to shove the values for each row into the right BO but when I change a property, OnPropertyChanged is called which then calls mNonSerializableHandlers.Invoke(sender, e).

But this is the ListChanged event. When it runs, the value in the first row of data is evaluated and if it causes the list to re-sort, then it does. Now my grid and BOs are no longer "lined up" and there is a huge mess during unbinding.

I am pretty sure the code in the objectListView is supposed to react to that event and re-order the list on the fly - but I don't want it to happen during unbinding in my Web app.

Any advice?

Joe

DavidDilworth replied on Tuesday, October 30, 2007

Joe,
I looked at the CSLA framework classes and I see what you mean. Strictly speaking the Child_PropertyChanged() handler is kicking in because you've changed a property of a child object inside the list - you've not actually changed the list. That's why the RaiseListChangedEvents flag (from the .NET framework BindingList<T> class) has no effect.

But I can absolutely see why you would expect the behaviour you describe.

I know it sounds obvious and you probably don't want to do it. I guess you've considered "patching" your CSLA base class to add "support" for the RaiseListChangedEvents flag into the Child_PropertyChanged() method?

JoeFallon1 replied on Tuesday, October 30, 2007

David,

Thanks for taking a look. This isn't obvious or trivial.

I decided to add this code to my Base class that inherits from CSLA BusinessBase:

Protected mDisablePropertyChanged As Boolean

Protected Overrides Sub OnPropertyChanged(ByVal propertyName As String)
If mDisablePropertyChanged Then
'do nothing
Else
MyBase.OnPropertyChanged(propertyName)
End If
End Sub

Then in the BO that is contained in the collection I set mDisablePropertyChanged = True during DP_Create and Fetch.

This means that all other BOs act as they always have but for this BO the event is not raised.

It solved the issue during unbinding so that the sorted list is not re-arranged too soon.

Joe