Design question: owned collection items?

[Jens Weiermann]

Hi,

I have a basic design question here: I've created a custom (typed)
collection by deriving from CollectionBase. Now I need to have "owned"
collection items to be able to notify the collection if properties of the
items change. By "owned" I mean that the items need to "know" which
collection (if any) they're in. But it must also be possible that these
items live "outside" a collection.
My first thought was to override the OnInsertComplete, OnRemoveComplete and
OnSetComplete methods and write to the added/removed/set items there.
Is there any better approach to this?

Thanks!
Jens

 

[Larry Lard]

Hi,

I have a basic design question here: I've created a custom (typed)
collection by deriving from CollectionBase. Now I need to have "owned"
collection items to be able to notify the collection if properties of the
items change. By "owned" I mean that the items need to "know" which
collection (if any) they're in.

This is two different things you're talking about.

- to have the collection be aware of changes to contained objects, the
contained objects need to define a Changed event and raise this when
something changes; then in the Add method of the collection, hook up to
the Changed event of the incoming item (and unhook in the Remove
method)

- to have the objects know they're in a collection, they need to have a
Container property, which you would again set/unset in the Add/Remove
methods. But you don't need to do this if you just want to listen for
changes

Note that an event model would be the preferred way of communicating
the fact something's changed; it shouldn't be the object's job to check
whether anyone is listening for changes, after all there could be none,
one, or many listeners; the object just raises the event and anyone who
cares can listen for that event.

 

[Jens Weiermann]

Note that an event model would be the preferred way of communicating
the fact something's changed; it shouldn't be the object's job to check
whether anyone is listening for changes, after all there could be none,
one, or many listeners; the object just raises the event and anyone who
cares can listen for that event.

I thought of that as well, but was afraid that using events would cause
performance loss. But now that I'm thinking a little more about it, I guess
that's not true...

Thanks for your answer!
Jens