Dispose Again!

[Michael C#]

Re: Dispose Again!

Thanks Jay.

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:%236kPRkpL FHA.1528@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> Michael,
> I sent a question or two to MS on this. I will post here if I get anthing
> to satiate your questions & concerns....
>
> Hope this helps
> Jay
>
> "Michael C#" <xyz@abcdef.com > wrote in message
> news:oOK%d.785$ 7P6.670@fe10.lg a...[color=green]
>> Has anyone from Microsoft itself weighed in on this, or are the
>> MS-employed Developers steering clear of this train wreck? I personally
>> would like to hear it from the horse's mouth once and for all.
>>[/color]
>
>[/color]

[Michael C#]

Re: Dispose Again!

"Scott M." <s-mar@nospam.nosp am> wrote in message
news:er3HrgpLFH A.2384@tk2msftn gp13.phx.gbl...[color=blue]
> You have heard if from the horses mouth, over and over in this thread:
>
> When a class uses unmanaged resources and exposes a Dispose method, call
> the Dispose method.
>
> This is what virtually all documentation on Dispose says. The rest of
> this thread is academic.[/color]

Yes yes, I think you're confusing the horse's orifices again. Is this *all*
that the documentation says? This is a great, nice, wonderful sound bite,
and I'm sure it's just dandy if you're developing your own class which uses
unmanaged resources.

Now, which of the classes built into the .NET Framework "use unmanaged
resources", and which don't? Simple question right?

[Cor Ligthert]

Re: Dispose Again!

Jay,

Thanks,
[color=blue]
>That section of code is explained here:
>http://www.vbinfozine.com/a_disposable_comp.shtml[/color]

I never saw it, however the recommendation in the last rows on that page is
almost exactly the same as I did in this thread.

Cor

[Michael C#]

Re: Dispose Again!

"Scott M." <s-mar@nospam.nosp am> wrote in message
news:er3HrgpLFH A.2384@tk2msftn gp13.phx.gbl...[color=blue]
> You have heard if from the horses mouth, over and over in this thread:
>
> When a class uses unmanaged resources and exposes a Dispose method, call
> the Dispose method.
>
> This is what virtually all documentation on Dispose says. The rest of
> this thread is academic.
>[/color]

Scott, no offense, but your every time I read your responses I am - for some
reason or other - reminded of the "Microsoft helicopter joke." While your
responses are - I'm sure - technically accurate, I'm not finding them overly
useful in addressing my only simple question. So I shall rephrase more
precisely: By *name*, *exactly* which classes, of the classes built into
the .NET Framework (*no user-created classes*), absolutely *require* the use
of Dispose() - and *exactly* which ones don't?

I don't need consultant-like broad generalizations and sound bites rehashed
from the Marketing Department. I need to know exactly which classes need to
be disposed and which do not. That's all. End of story.

If all you have is another quote from the Book of Architects like this one
(Chapter 12, Verse 13): "Useth Dispose only on classes uponeth which it is
required of thee, but neither on classes on which it is not exposed; nor on
classes that inherit it, excepting that it hath been overridden as a plague
of locusts upon the keyboard; or upon classes wherein thy development has
forsaken thy managed resources and delveth into thine pool of unmanaged
resources. Then shalt thou call they Dispose method. 'Thy Finalize shalt
not use thy Dispose in vain,' sayeth the Scott, 'only thine class user shall
ever calleth thy Dispose as this is the way of things.' And out of the
darkness the people cheered and feasted upon the potato chips and Mountain
Dew and they coded and were once again happy...", then you can, for all
intents and purposes, save it for surprise ending to a book.

[Michael C#]

Re: Dispose Again!

OK Got it. Learn IL, then use Object Browser and Reflector to observe the
objects...

Y'Know, if someone would just write a book called ".NET Dispose() List" or
some such crap, with a complete listing of all built-in Framework classes
that require Dispose to be used, I'd be second in line to buy the damn
thing. I thought the .NET Framework was going to make life easier - but
sometimes it seems that old problems were just exchanged for their 21st
century equivalents.


"David" <dfoster@woofix .local.dom> wrote in message
news:slrnd3ujab .rf.dfoster@woo fix.local.dom.. .[color=blue]
> On 2005-03-22, Michael C# <xyz@abcdef.com > wrote:[color=green]
>>
>> "David" <dfoster@woofix .local.dom> wrote in message
>> news:slrnd3ubju .fa.dfoster@woo fix.local.dom.. .[color=darkred]
>>> On 2005-03-22, Michael C# <xyz@abcdef.com > wrote:
>>>> Now see, this is where the confusion comes in. You say Forms controls
>>>> should always be disposed - yet others say Dispose is not necessary on
>>>> a
>>>> Label... Is the Label an "exception" ? Or should Forms controls,
>>>> including
>>>> the Label, be disposed?
>>>
>>> I know what Component.Dispo se does, and MarshallByRefCo mponent.Dispose ,
>>> etc. So
>>> the only issue is whether the class itself implements a needed Dispose
>>> override, and that only takes a second to check.[/color]
>>
>> This is the information I need! How do you determine if a class
>> implements
>> a *needed* Dispose override, as opposed to an unnecessary one? So far
>> I've
>> been given the run-around on this particular question with a lot of
>> inadequate answers.[/color]
>
> Personally, I just pull up Reflector (or even ildasm) and look at the
> class. IL is pretty readable. Often, component-derived classes don't
> even implement Dispose, it's just there from the base class.
>[color=green]
>> That makes sense, although I haven't encountered that problem to date -
>> and
>> I'd think that a destructive Dispose would make itself known via
>> crashing,
>> etc., far before the product made its way out of development.[/color]
>
> Well, that assumes we're in development. For example, I tend to load a
> lot of things through reflection, so I can't really be sure what I'm
> getting during development is what I'm getting in production.
>
> But for the most part, we're probably talking about a new version of
> .NET, and for that I expect major dispose changes to be fairly well
> known (if not documented by MS, they'll still show up on mailing lists,
> etc.).
>[color=green]
>> But stranger
>> things have happened I suppose. How much of a memory leak you're willing
>> to
>> tolerate probably depends on a lot of factors, I would imagine.
>>[color=darkred]
>>> I'm not saying this is right, just that it's a trade-off. Dispose is
>>> basically a hole in the Framework due to (necessary) limitations of the
>>> GC. I don't think there's a simple one-size-fits-all solution to it.[/color]
>>
>> I think the best solution, from my point of view, would be better
>> information about when - and when not - to call it. As of now it seems
>> like
>> quite a hindrance.[/color]
>
> Agreed. For example, here's a nagging question. If I don't dispose an
> IDbConnection, am I holding onto resources too long? But if I do
> dispose it, what effect does that have on the connection pool
> (presumably the pool can't reuse a Disposed connection, right?).
>
> There's really no way to answer that without knowing the internals of
> the class, but the whole point of using the interface (instead of a
> concrete class) in the first place was so that my code didn't have to
> know the internals of the class.
>
> That's a problem I still haven't figured out a decent answer to.
>
>[/color]

[Michael C#]

Re: Dispose Again!

The outer-workings of the class seem to be fairly simple. You look at the
properties and methods exposed and determine what functionality the class
provides. Maybe you have an example of what you're talking about and how
this relates to Dispose()? Thanks

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:OQcqe6uLFH A.656@TK2MSFTNG P14.phx.gbl...[color=blue]
> Doh!
>[color=green]
>> are subject to change. What I intended on stating is that you need to
>> learn the "intent" or the workings of the class![/color]
> That should read "the "intent" or outer workings of the class
>
> Jay
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
> news:%23asM7VpL FHA.244@TK2MSFT NGP12.phx.gbl.. .[color=green]
>> Michael,[color=darkred]
>>> The bottom line is that you have given no substantial reason to waste
>>> time researching and categorizing when to call, and when not to call,
>>> Dispose() on classes that expose it.[/color]
>> Exactly!!!!!
>>
>> I have not given a substantial reason as IMHO there is no substantial
>> reason! I believe I stated (at least implied) I would not waste time
>> researching & categorizing when to call or not call Dispose.
>>
>> As JD, David & myself have tried to state: We work with a certain set of
>> classes, by experience we have learned which need to be disposed & which
>> do not.
>>[color=darkred]
>>> As for learning the inner workings of classes in the .NET Framework, I[/color]
>> I don't believe I stated inner workings, I definitely did not mean to
>> imply inner workings, as I consider inner workings as implementation
>> details that are subject to change. What I intended on stating is that
>> you need to learn the "intent" or the workings of the class! I hope you
>> agree that learning the intent of a class is important before you just
>> start "throwing code together".
>>
>> Hope this helps
>> Jay
>>
>>
>>
>>
>> "Michael C#" <xyz@yomomma.co m> wrote in message
>> news:eEYp%23plL FHA.576@TK2MSFT NGP15.phx.gbl.. .[color=darkred]
>>> None of your links provide a definitive list of when to call Dispose()
>>> on classes built into the .NET Framework Library. Not even the one that
>>> describes how to implement Dispose in your own classes.
>>>
>>> Based on what you've said, the only reason I can see for dilly-dallying
>>> around Dispose() and not using it every single doggone time is for
>>> bragging rights and self-stroking of one's ego (i.e., "I have this
>>> esoteric knowledge, so I am better than a mere 'programmer'".) The
>>> bottom line is that you have given no substantial reason to waste time
>>> researching and categorizing when to call, and when not to call,
>>> Dispose() on classes that expose it.
>>>
>>> As for learning the inner workings of classes in the .NET Framework, I
>>> always thought the entire point of High-Level OO Programming was to
>>> provide programmers with "clock-work" functionality that they could
>>> count on to work consistently without having to know how many "gears
>>> were in the box", or the specific "gear measurements", etc. After all,
>>> if everything you've created relies on the turning of those gears, what
>>> do you do with your work when they switch you over to a digital clock?
>>> Case in point, why in the world do I, while programming VB.NET, need to
>>> know that the Framework sets the AH, BX, CX, DX, SI and DS registers
>>> before an INT 21H call in order to open a file for me?
>>>
>>> I was under the impression that the programmer should be shielded from
>>> the inner tinkerings of the class, and that all you really need to -- or
>>> should -- rely on is the fact that "if I passeth in 'X' it shall
>>> performeth 'Y' and returneth 'Z'"; and that you shouldn't bet the farm
>>> on the internal workings of a class always achieving their results in
>>> the same manner as they appear to do today. But that's just the
>>> "programmer " in me talking, not "Le Architect".
>>>[/color]
>>
>>[/color]
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Michael,[color=blue]
> I'm not finding them overly useful in addressing my only simple question.[/color]
IMHO This thread has definitely shows that this is not a simple question!
:-)

[color=blue]
> I need to know exactly which classes need to be disposed and which do not.
> That's all.[/color]
IMHO Its not that simple (yes I may even say it is down right esoteric ;-))

Consider objects that inherit from System.Windows. Forms.Form:

Dim dialog As New OptionsDialog ' inherits Form
dialog.ShowDial og()
dialog.Dispose( )

Dim child As New MidChildForm ' inherits Form
child.Show()

The form in the "dialog" variable requires Dispose being called, while the
form in the "child" variable does not. As Form.Show causes the form to call
Dispose for you in the Close event. While ShowDialog does not; allowing you
to retrieve values from the dialog's controls after the user closes the
form.
[color=blue]
> By *name*, *exactly* which classes, of the classes built into the .NET
> Framework (*no user-created classes*), absolutely *require* the use of
> Dispose() - and *exactly* which ones don't?[/color]
Consider System.Windows. Forms.Label. It is correct to state, as others have,
you don't need to (explicitly) call Dispose on Label, as normally a Form
"owns" the label, when you dispose the Form the label will be (implicitly)
Disposed. http://www.vbinfozine.com/a_disposable_comp.shtml However I have
seen reports of some third party controls that don't dispose correctly when
placed on forms...

Hope this helps
Jay

"Michael C#" <xyz@yomomma.co m> wrote in message
news:uupttQvLFH A.132@TK2MSFTNG P10.phx.gbl...[color=blue]
> "Scott M." <s-mar@nospam.nosp am> wrote in message
> news:er3HrgpLFH A.2384@tk2msftn gp13.phx.gbl...[color=green]
>> You have heard if from the horses mouth, over and over in this thread:
>>
>> When a class uses unmanaged resources and exposes a Dispose method, call
>> the Dispose method.
>>
>> This is what virtually all documentation on Dispose says. The rest of
>> this thread is academic.
>>[/color]
>
> Scott, no offense, but your every time I read your responses I am - for
> some reason or other - reminded of the "Microsoft helicopter joke." While
> your responses are - I'm sure - technically accurate, I'm not finding them
> overly useful in addressing my only simple question. So I shall rephrase
> more precisely: By *name*, *exactly* which classes, of the classes built
> into the .NET Framework (*no user-created classes*), absolutely *require*
> the use of Dispose() - and *exactly* which ones don't?
>
> I don't need consultant-like broad generalizations and sound bites
> rehashed from the Marketing Department. I need to know exactly which
> classes need to be disposed and which do not. That's all. End of story.
>
> If all you have is another quote from the Book of Architects like this one
> (Chapter 12, Verse 13): "Useth Dispose only on classes uponeth which it
> is required of thee, but neither on classes on which it is not exposed;
> nor on classes that inherit it, excepting that it hath been overridden as
> a plague of locusts upon the keyboard; or upon classes wherein thy
> development has forsaken thy managed resources and delveth into thine pool
> of unmanaged resources. Then shalt thou call they Dispose method. 'Thy
> Finalize shalt not use thy Dispose in vain,' sayeth the Scott, 'only thine
> class user shall ever calleth thy Dispose as this is the way of things.'
> And out of the darkness the people cheered and feasted upon the potato
> chips and Mountain Dew and they coded and were once again happy...", then
> you can, for all intents and purposes, save it for surprise ending to a
> book.
>[/color]

[Michael C#]

Re: Dispose Again!

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:%23GywAJwL FHA.3296@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> Consider objects that inherit from System.Windows. Forms.Form:
>
> Dim dialog As New OptionsDialog ' inherits Form
> dialog.ShowDial og()
> dialog.Dispose( )
>
> Dim child As New MidChildForm ' inherits Form
> child.Show()[/color]

See, now we're making progress. Two down. Now how many classes does that
leave? :)

[Cor Ligthert]

Re: Dispose Again!

Jay,

I was always curious about this and because of this thread I tested it.
[color=blue]
> Dim dialog As New OptionsDialog ' inherits Form
> dialog.ShowDial og()
> dialog.Dispose( )
>[/color]
I tested it just with a breakpoint in the showdialog at the disposing part.
(because that the dispose is overriden in every form is that easy)
When I do
dim frm as new form2
frm.showdialog
frm.dispose ' it is called directly
When I do
dim frm as new form2
frm.showdialog
frm.close ' the same routine is called when the mainform is closing.

I hope this helps

Cor

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Michael,[color=blue]
> See, now we're making progress. Two down.[/color]
I would consider it one type, that is System.Windows. Forms.Form.

Consider a variation of the sample:

Dim dialog As Form

dialog = New OptionsDialog
dialog.ShowDial og()
dialog.Dispose( )

dialog = New OptionsDialog
dialog.Show()

Its the exact same form, however based on how it is shown (Form.ShowDialo g
or Form.Show) changes if Dispose is needed or not...
[color=blue]
> Now how many classes does that leave? :)[/color]
The following page suggests there are 85 classes. I'm not sure if that only
includes types directly implementing IDisposable or if it includes types
that inherit IDisposable from a base class also.

http://www.vbinfozine.com/a_disposable.shtml

I think the rule that is tripping people up (including the way I have stated
things) is when IDisposable is in a base class (such as Component).

Hope this helps
Jay


"Michael C#" <xyz@yomomma.co m> wrote in message
news:%23PIzINwL FHA.3760@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
> news:%23GywAJwL FHA.3296@TK2MSF TNGP15.phx.gbl. ..[color=green]
>> Consider objects that inherit from System.Windows. Forms.Form:
>>
>> Dim dialog As New OptionsDialog ' inherits Form
>> dialog.ShowDial og()
>> dialog.Dispose( )
>>
>> Dim child As New MidChildForm ' inherits Form
>> child.Show()[/color]
>
> See, now we're making progress. Two down. Now how many classes does that
> leave? :)
>[/color]

[Cor Ligthert]

Re: Dispose Again!

Michael,

A factor I use (however learned from what I read) for dispose is how
big/(how many it include) is the resource that is used.

When you are using a big bitmap/pens, and you know that your program will
maybe run on computers with by instance not to much memory, than that can be
a reason to dispose it as soon as possible. (Another one for me is creating
a lot in a recursive loop).

And because that nobody knows that memory question in advance, is it for me
good practise to dispose those as soon as possible.

Probably you knew this already

:-)

Cor

[Michael C#]

Re: Dispose Again!

I knew about the bitmaps and pens, but hadn't really thought about the
recursive loop issue. Thanks for the food for thought.

"Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
news:O2IgNQxLFH A.2252@TK2MSFTN GP15.phx.gbl...[color=blue]
> Michael,
>
> A factor I use (however learned from what I read) for dispose is how
> big/(how many it include) is the resource that is used.
>
> When you are using a big bitmap/pens, and you know that your program will
> maybe run on computers with by instance not to much memory, than that can
> be a reason to dispose it as soon as possible. (Another one for me is
> creating a lot in a recursive loop).
>
> And because that nobody knows that memory question in advance, is it for
> me good practise to dispose those as soon as possible.
>
> Probably you knew this already
>
> :-)
>
> Cor
>[/color]

[Michael C#]

Re: Dispose Again!

Ahh, one down, 85 times X variations to go :) It seems like there are a lot
more than 85 classes, however. But then again, I might be counting classes
that are automatically excluded by virtue of not implementing Dispose()
anyway.

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:OH1pXJxLFH A.1156@TK2MSFTN GP09.phx.gbl...[color=blue]
> Michael,[color=green]
>> See, now we're making progress. Two down.[/color]
> I would consider it one type, that is System.Windows. Forms.Form.
>
> Consider a variation of the sample:
>
> Dim dialog As Form
>
> dialog = New OptionsDialog
> dialog.ShowDial og()
> dialog.Dispose( )
>
> dialog = New OptionsDialog
> dialog.Show()
>
> Its the exact same form, however based on how it is shown (Form.ShowDialo g
> or Form.Show) changes if Dispose is needed or not...
>[color=green]
>> Now how many classes does that leave? :)[/color]
> The following page suggests there are 85 classes. I'm not sure if that
> only includes types directly implementing IDisposable or if it includes
> types that inherit IDisposable from a base class also.
>
> http://www.vbinfozine.com/a_disposable.shtml
>
>
> I think the rule that is tripping people up (including the way I have
> stated things) is when IDisposable is in a base class (such as Component).
>
> Hope this helps
> Jay
>
>
> "Michael C#" <xyz@yomomma.co m> wrote in message
> news:%23PIzINwL FHA.3760@TK2MSF TNGP12.phx.gbl. ..[color=green]
>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
>> news:%23GywAJwL FHA.3296@TK2MSF TNGP15.phx.gbl. ..[color=darkred]
>>> Consider objects that inherit from System.Windows. Forms.Form:
>>>
>>> Dim dialog As New OptionsDialog ' inherits Form
>>> dialog.ShowDial og()
>>> dialog.Dispose( )
>>>
>>> Dim child As New MidChildForm ' inherits Form
>>> child.Show()[/color]
>>
>> See, now we're making progress. Two down. Now how many classes does
>> that leave? :)
>>[/color]
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Cor,[color=blue]
> frm.showdialog
> frm.close ' the same routine is called when the mainform is closing.[/color]
Yes same routine but for different reason, look at what the disposing
parameter is.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsFormsFormClassDisposeTopic1.asp

In my test it was called by Finalize not Dispose, which in the ShowDialog
case I would expect, as that is what the following states:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsFormsFormClassCloseTopic.asp

Try putting Me.Close in a button click event on the form. Use both
Form.ShowDialog & Form.Show to show the form. Notice the difference?

Try the following code:

'Form overrides dispose to clean up the component list.
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)

Debug.WriteLine (disposing, "Dispose")

If disposing Then
If Not (components Is Nothing) Then
components.Disp ose()
End If
End If
MyBase.Dispose( disposing)
End Sub

Private Sub buttonClose_Cli ck(ByVal sender As System.Object, ByVal e As
System.EventArg s) Handles buttonClose.Cli ck
Debug.WriteLine ("Before close", "buttonClose_Cl ick")
Me.Close()
Debug.WriteLine ("After close", "buttonClose_Cl ick")
End Sub

Public Shared Sub Main()
Dim dialog As New MainForm
dialog.ShowDial og()
Debug.WriteLine ("Before close", "Main")
dialog.Close()
Debug.WriteLine ("After close", "Main")

Application.Run (New MainForm) ' do dialog.Show

End Sub

Hope this helps
Jay

"Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
news:ODRgGSwLFH A.3812@TK2MSFTN GP10.phx.gbl...[color=blue]
> Jay,
>
> I was always curious about this and because of this thread I tested it.
>[color=green]
>> Dim dialog As New OptionsDialog ' inherits Form
>> dialog.ShowDial og()
>> dialog.Dispose( )
>>[/color]
> I tested it just with a breakpoint in the showdialog at the disposing
> part.
> (because that the dispose is overriden in every form is that easy)
> When I do
> dim frm as new form2
> frm.showdialog
> frm.dispose ' it is called directly
> When I do
> dim frm as new form2
> frm.showdialog
> frm.close ' the same routine is called when the mainform is closing.
>
> I hope this helps
>
> Cor
>
>
>[/color]

[Michael C#]

Re: Dispose Again!


"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:eCc7WRyLFH A.1308@TK2MSFTN GP15.phx.gbl...[color=blue]
> Cor,[color=green]
>> frm.showdialog
>> frm.close ' the same routine is called when the mainform is closing.[/color]
> Yes same routine but for different reason, look at what the disposing
> parameter is.
>
>
> http://msdn.microsoft.com/library/de...poseTopic1.asp[/color]

Uh-oh. You mean to tell me that for this class, Finalize invoketh Dispose?