Singleton ReadonlyListBase

ajj3085 posted on Wednesday, September 05, 2007

Hi all,

My users finally noticed; if they create a new company / department while having another window open when uses dropdowns for company and departments, the second window does NOT list the new company or department.  They would like this addressed.

Currently, my CompanyList has a static property List, which is used to grab the list and put into the BindingSource.  The actual list returned is cached, and when a Company is saved, the cache is flushed and reloaded on next request.

Obviously, the Bindingsource is using the 'old' cached copy.  So I was thinking to create a true Singleton. Instead of throwing the old list out, and loading a new one up that I would shut off ListChanged events, clear the list, and re-populate it, then raise a ListChanged Reset.

Has anyone done this?  What are the drawbacks?  Will my quote window now lose the company / department that is already selected, or will things work correctly still because the business objects compare based on the primary key?

Thanks
Andy

mr_lasseter replied on Wednesday, September 05, 2007

Why not have your ReadOnlyList listen to a static event thrown by your Editable object when the Editable Object is saved.  Then in the ReadOnlyList you would either add\update its readonly counterpart.  I have used this in my application and it works great. 

ajj3085 replied on Wednesday, September 05, 2007

Hmm, interesting idea, I didn't know about static events.  Does this cause any problems with garbage collection though?  Or is the event handler static as well?

mr_lasseter replied on Wednesday, September 05, 2007

The event handler is static as well.  Check out Rocky's blog post.

http://www.lhotka.net/weblog/IAmWorkingOnMyUsingCSLANET30EbookAndWroteSomeContentThatIDontThinkImGoingToUseInTheBook.aspx

In my application, I actually use the Observer.dll that was part of ActiveObjects to do this, which works quite well.  But Rocky's example looked much simpler.  I have considered modifying my code, but I thought if it ain't broke don't touch it. 

ajj3085 replied on Thursday, September 06, 2007

Thanks for the link, I'll check it out.

I agree with the 'not broke, don't fix' although I do tend to try and simplify code where I can.  Unit tests can help make this a bit easier.

ajj3085 replied on Thursday, September 06, 2007

I checked out the article, and the first comment discusses a memory leak, which Rocky acknowledges.

At any rate, both methods (the one I thought up, and your static event) wide up modifying an existing list, so I think I'll go ahead and go with my Singleton list (since that's what both methods end up with anyway).

Thanks
Andy