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.
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.
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;
}
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
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.
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.
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.
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