Discover not disposed objects

[Crirus]

Is there a way to catch undisposed objects that only occupy memory, in order
to call dispose for them?
I may be forgetting to dispose fonts, pens, graphics sometimes... how to
find them (without reading the whole code again:))

--
Cheers,
Crirus

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

[Herfried K. Wagner [MVP]]

* "Crirus" <Cr****@datagroup.ro> scripsit:

Is there a way to catch undisposed objects that only occupy memory, in order
to call dispose for them?
I may be forgetting to dispose fonts, pens, graphics sometimes... how to
find them (without reading the whole code again:))

I don't know if there is a tool to "automate" that, but keep the code
compact, structure it in procedures -- so you won't "forget" to
dispose...

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Jay B. Harlow [MVP - Outlook]]

Crirus,
When we get Whidbey (VB.NET 2004 later in 2004) we will have a Using
statement that will call Dispose automatically for us!

Until then:

Is there a way to catch undisposed objects that only occupy memory, in order to call dispose for them? With out a reference to the said object, you will not be able to call the
Dispose method. Normally classes that implement Dispose also implement the
Finalize method. The Dispose method will disable calling Finalize, while the
Finalize method will call the Dispose method...

http://msdn.microsoft.com/library/de...izeDispose.asp

If a class implements the Finalize method, then the GC will eventually call
the Finalize method. Hence the GC should eventually call the Dispose
method...

You can use the CLR profiler to help identify objects that need to be
finalize, this may lead you to the objects that need to be Disposed of.

http://www.microsoft.com/downloads/d...displaylang=en

I believe you could use one of the many Code Critics/Code Analyzers out
there to identify objects that have not been disposed:

Such as:
http://www.fmsinc.com/dotnet/analyzer/

At least I would expect a Code Critic/Analyzer to report objects that were
not disposed!

Hope this helps
Jay
"Crirus" <Cr****@datagroup.ro> wrote in message
news:OF**************@TK2MSFTNGP12.phx.gbl... Is there a way to catch undisposed objects that only occupy memory, in order to call dispose for them?
I may be forgetting to dispose fonts, pens, graphics sometimes... how to
find them (without reading the whole code again:))

--
Cheers,
Crirus

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

[Tom Shelton]

In article <OF**************@TK2MSFTNGP12.phx.gbl>, Crirus wrote:

Is there a way to catch undisposed objects that only occupy memory, in order
to call dispose for them?
I may be forgetting to dispose fonts, pens, graphics sometimes... how to
find them (without reading the whole code again:))

There is no way, once you've released all references...

For custom classes, though it was decided over on the C# group that the
best solution is to throw an exception from your finalize method. Sure,
it brings your program down - but you know when you forgot to dispose of
an object :)

--
Tom Shelton
MVP [Visual Basic]

[Jay B. Harlow [MVP - Outlook]]

Tom,
Throwing an exception in your Finalize method is a good idea!

As long as you implement the Disposable Finalize pattern correctly ;-)

http://msdn.microsoft.com/library/de...izeDispose.asp

Just a thought
Jay

"Tom Shelton" <to*@mtogden.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

In article <OF**************@TK2MSFTNGP12.phx.gbl>, Crirus wrote:

Is there a way to catch undisposed objects that only occupy memory, in order to call dispose for them?
I may be forgetting to dispose fonts, pens, graphics sometimes... how to
find them (without reading the whole code again:))

There is no way, once you've released all references...

For custom classes, though it was decided over on the C# group that the
best solution is to throw an exception from your finalize method. Sure,
it brings your program down - but you know when you forgot to dispose of
an object :)

--
Tom Shelton
MVP [Visual Basic]

[Tom Shelton]

In article <OY**************@TK2MSFTNGP12.phx.gbl>, Jay B. Harlow [MVP - Outlook] wrote:

Tom,
Throwing an exception in your Finalize method is a good idea!

As long as you implement the Disposable Finalize pattern correctly ;-)

http://msdn.microsoft.com/library/de...izeDispose.asp

Just a thought
Jay

Yeah, I of course should have mentioned that - but I guess I assumed
that was understood :)

Actually, I thought it was pretty clever myself and am starting to use
that it in my own objects. This way you always know when Finalize has
been called :)

--
Tom Shelton
MVP [Visual Basic]

[Crirus]

Wel, my concerns are related to pens, graphics, brushes..etc... the graphics
stuffs..that ones I use most.. my own classes are not to me dispasable as
long as application run

--
Cheers,
Crirus

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

"Tom Shelton" <to*@mtogden.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

In article <OF**************@TK2MSFTNGP12.phx.gbl>, Crirus wrote:

Is there a way to catch undisposed objects that only occupy memory, in order to call dispose for them?
I may be forgetting to dispose fonts, pens, graphics sometimes... how to
find them (without reading the whole code again:))

There is no way, once you've released all references...

For custom classes, though it was decided over on the C# group that the
best solution is to throw an exception from your finalize method. Sure,
it brings your program down - but you know when you forgot to dispose of
an object :)

--
Tom Shelton
MVP [Visual Basic]

[Jay B. Harlow [MVP - Outlook]]

Tom,
An alternative to throwing an exception is to use Debug.Fail.

I will use Debug.Fail when I want the message in the debugger, however I do
not want the message in the release build.

As technically not calling Dispose is not an error.

Just a thought
Jay

"Tom Shelton" <to*@mtogden.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

In article <OY**************@TK2MSFTNGP12.phx.gbl>, Jay B. Harlow [MVP -

Outlook] wrote:

Tom,
Throwing an exception in your Finalize method is a good idea!

As long as you implement the Disposable Finalize pattern correctly ;-)

http://msdn.microsoft.com/library/de...izeDispose.asp
Just a thought
Jay

Yeah, I of course should have mentioned that - but I guess I assumed
that was understood :)

Actually, I thought it was pretty clever myself and am starting to use
that it in my own objects. This way you always know when Finalize has
been called :)

--
Tom Shelton
MVP [Visual Basic]