I assume you dispose on shutting down. So the referencing objects(tasks) will also be disposed soon?
Trivial approach would be to have (two or more) synchronised methods: writeToConsole dispose The dispose method sets the disposedFlag to true and then does all the wipe up. The writeToConsole-method checks the disposedFlag before writing to the writer. This could also be implemented using the state-pattern (and Null/DummyObject-pattern) within the singleton. Regards Clemens > -----Original Message----- > From: Robin Debreuil [mailto:[EMAIL PROTECTED] > Sent: Freitag, 20. Juni 2003 07:52 > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Singletons and dispose... > > > Sorry in advance if this has an obvious answer. I'm making an > application > that runs tasks, which are plugins. One of the things it has to do is > capture console output, and log/filter/display/forward it. > What I've done > (and this is always where things seem to start breaking > down), is write a > class that essentially intercepts the console and makes the > output available > via events to whoever needs it. > > So the problem is I don't want a second instance hijacking > the console, as > it would disconnect the first. So it seems a job for a > singleton at some > point. However there are textWriters in there that need to be > Closed, a > Timer that need to be Disposed, and resetting the console... > So IDisposable > seems in order too. Of course once someone calls dispose and > the instance is > singleton, anything with a reference to it is going to have a > problem. I was > thinking of putting the dispose stuff in finalize, but that > seems very wrong > too. I guess some defensive code in Dispose could work, but > really there > shouldn't be a dispose available if you don't want it called > it seems, no? > Maybe the 'singleton' part should just be a class that knows > about a second > secret class that does all this stuff? Or...? > > Thanks, > Robin >
