Child property changes in CSLA 3.5.1 do not cause BusinessListBase to reindex

Child property changes in CSLA 3.5.1 do not cause BusinessListBase to reindex

Old forum URL: forums.lhotka.net/forums/t/6780.aspx


rsbaker0 posted on Sunday, April 12, 2009

I'm finding changes to an indexed object in the list do not cause it to be reindexed.

This appears to be because Child_PropertyChanged is not being hooked to PropertyChanged for objects in my list.

The only reference I can find for Child_PropertyChanged being set as the event handler is in OnDeserialized, so I'm not sure how this works with a local data portal.

RockfordLhotka replied on Monday, April 13, 2009

The way the .NET collection base class (BindingList<T>) handles PropertyChanged is odd (broken I think).

They automatically hook the child object's PropertyChanged events and raise a corresponding ListChanged. However, on deserialization they don't automatically rehook the event processing, and so CSLA has to basically reimplement the code from BindingList<T>. Very sad really.

But this is why the only explicit hooking of PropertyChanged is on deserialization - because otherwise PropertyChanged is hooked automatically by BindingList<T> itself, outside of the control of my code.

rsbaker0 replied on Monday, April 13, 2009

Can you suggest any way I can trouble-shoot this?

I must be doing something in my list construction that prevents the event from being hooked the first time, but I sure can't see what it is.

(1) Newly fetched list: Child_PropertyChanged never called

(2) Once list deserialized: Child_PropertyChanged called when property changed.

My BLB class basically reads some objects fetched by the ORM from the database and calls a routine that looks like this:

        public void Add(IEnumerable list)
        {
            // Stop raising events while the list is modified
            RaiseListChangedEvents = false;

            foreach (object o in list)
            {
                // Get each object to perform any initialization required on itself...
                C businessObject = (C)o;

                businessObject.Init(true);

                // ...and then add it to the list
                Add(businessObject);
            }

            // Start raising events again
            RaiseListChangedEvents = true;
        }

 

RockfordLhotka replied on Monday, April 13, 2009

I’m sorry, I’m not saying there’s not a bug in the code somewhere.

 

I’m just saying that the behavior of the list before and after deserialization is fundamentally different.

 

The Child_PropertyChanged method is designed to duplicate the behavior already in BindingList<T>. If we hooked that for a non-deserialized object it would break many things, because the behavior (or parts of it anyway) would run twice. At a minimum, the ListChanged event would get raised twice for each child change, and that’d be a serious mess.

 

Rocky

 

rsbaker0 replied on Monday, April 13, 2009

Just to clarify, what I'm observing is "normal"  -- e.g. Child_PropertyChanged isn't being called for my lists at all?

This gets me back to my original problem, which is that the internal LINQ index doesn't stay up to date with changes made to the data in the list after it is loaded.

 

RockfordLhotka replied on Monday, April 13, 2009

What you are observing is normal, assuming you aren’t serializing/deserializing your lists.

 

The original problem sounds like a bug, and it may have crept in when I was fixing the ChildChanged event handling for 3.6.2.

 

You are using 3.6.2?

 

Rocky

 

 

From: rsbaker0 [mailto:cslanet@lhotka.net]
Sent: Monday, April 13, 2009 1:35 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Child property changes in CSLA 3.5.1 do not cause BusinessListBase to reindex

 

Just to clarify, what I'm observing is "normal"  -- e.g. Child_PropertyChanged isn't being called for my lists at all?

This gets me back to my original problem, which is that the internal LINQ index doesn't stay up to date with changes made to the data in the list after it is loaded.

 



rsbaker0 replied on Monday, April 13, 2009

Thanks for your patience and help on this.  No, I'm using 3.5.1 for the time being.

It's not a big deal for me at the moment, but I was very concerned I had messed up some some fundamental part of the framework in my intermediate base class implementation.

 

 

RockfordLhotka replied on Monday, April 13, 2009

There are quite a few changes in the event handling from 3.6.1 to 3.6.2, much less 3.5.x. The ChildChanged handling was broken, and it has taken a couple revisions to (hopefully) get it working correctly. Obviously that affects the LINQ to CSLA index too.

 

Rocky

 

 

Copyright (c) Marimer LLC