By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,966 Members | 812 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,966 IT Pros & Developers. It's quick & easy.

Dispose Again!

P: n/a
Ok, I'm trying to dispose of every object that I create that has a dispose
method based on advice from this newsgroup. However, I'm not sure how to
dispose of the following object that was created inside a method call.

dim myvar as new object1
object1.dosomethingmethod(new object2)

Note that object 2 has a dispose method but how do I dispose of it unless I
do the following:

dim myvar as new object1
dim mydisposableobject as new object 2
object1.dosomethingmethod(mydisposableobject )
myotherobject.Dispose
--
Dennis in Houston
Nov 21 '05 #1
Share this Question
Share on Google+
156 Replies


P: n/a
Your second bit of code is your solution.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:1F**********************************@microsof t.com...
Ok, I'm trying to dispose of every object that I create that has a dispose
method based on advice from this newsgroup. However, I'm not sure how to
dispose of the following object that was created inside a method call.

dim myvar as new object1
object1.dosomethingmethod(new object2)

Note that object 2 has a dispose method but how do I dispose of it unless
I
do the following:

dim myvar as new object1
dim mydisposableobject as new object 2
object1.dosomethingmethod(mydisposableobject )
myotherobject.Dispose
--
Dennis in Houston

Nov 21 '05 #2

P: n/a
I thought so. I see lots of examples in MSDN that use the first code so I
guess they don't dispose of the objects and leave it to the GC.

"Scott M." wrote:
Your second bit of code is your solution.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:1F**********************************@microsof t.com...
Ok, I'm trying to dispose of every object that I create that has a dispose
method based on advice from this newsgroup. However, I'm not sure how to
dispose of the following object that was created inside a method call.

dim myvar as new object1
object1.dosomethingmethod(new object2)

Note that object 2 has a dispose method but how do I dispose of it unless
I
do the following:

dim myvar as new object1
dim mydisposableobject as new object 2
object1.dosomethingmethod(mydisposableobject )
myotherobject.Dispose
--
Dennis in Houston


Nov 21 '05 #3

P: n/a
>>lots of examples in MDSN.

Yes.. sloppy lazy and often wrong..

I guess if you do a lot of that sort of thing you can try to convert the
object to IDisposable and dispose of it if it succeeds.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:FF**********************************@microsof t.com...
I thought so. I see lots of examples in MSDN that use the first code so I
guess they don't dispose of the objects and leave it to the GC.

"Scott M." wrote:
Your second bit of code is your solution.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:1F**********************************@microsof t.com...
> Ok, I'm trying to dispose of every object that I create that has a
> dispose
> method based on advice from this newsgroup. However, I'm not sure how
> to
> dispose of the following object that was created inside a method call.
>
> dim myvar as new object1
> object1.dosomethingmethod(new object2)
>
> Note that object 2 has a dispose method but how do I dispose of it
> unless
> I
> do the following:
>
> dim myvar as new object1
> dim mydisposableobject as new object 2
> object1.dosomethingmethod(mydisposableobject )
> myotherobject.Dispose
>
>
> --
> Dennis in Houston


Nov 21 '05 #4

P: n/a
What! Microsoft Wrong...I thought they were perfect!

"Bob Powell [MVP]" wrote:
lots of examples in MDSN.


Yes.. sloppy lazy and often wrong..

I guess if you do a lot of that sort of thing you can try to convert the
object to IDisposable and dispose of it if it succeeds.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:FF**********************************@microsof t.com...
I thought so. I see lots of examples in MSDN that use the first code so I
guess they don't dispose of the objects and leave it to the GC.

"Scott M." wrote:
Your second bit of code is your solution.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:1F**********************************@microsof t.com...
> Ok, I'm trying to dispose of every object that I create that has a
> dispose
> method based on advice from this newsgroup. However, I'm not sure how
> to
> dispose of the following object that was created inside a method call.
>
> dim myvar as new object1
> object1.dosomethingmethod(new object2)
>
> Note that object 2 has a dispose method but how do I dispose of it
> unless
> I
> do the following:
>
> dim myvar as new object1
> dim mydisposableobject as new object 2
> object1.dosomethingmethod(mydisposableobject )
> myotherobject.Dispose
>
>
> --
> Dennis in Houston


Nov 21 '05 #5

P: n/a
I think that spelt "perfict" ;-)

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:7B**********************************@microsof t.com...
What! Microsoft Wrong...I thought they were perfect!

"Bob Powell [MVP]" wrote:
>>lots of examples in MDSN.


Yes.. sloppy lazy and often wrong..

I guess if you do a lot of that sort of thing you can try to convert the
object to IDisposable and dispose of it if it succeeds.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:FF**********************************@microsof t.com...
>I thought so. I see lots of examples in MSDN that use the first code so
>I
> guess they don't dispose of the objects and leave it to the GC.
>
> "Scott M." wrote:
>
>> Your second bit of code is your solution.
>>
>> "Dennis" <De****@discussions.microsoft.com> wrote in message
>> news:1F**********************************@microsof t.com...
>> > Ok, I'm trying to dispose of every object that I create that has a
>> > dispose
>> > method based on advice from this newsgroup. However, I'm not sure
>> > how
>> > to
>> > dispose of the following object that was created inside a method
>> > call.
>> >
>> > dim myvar as new object1
>> > object1.dosomethingmethod(new object2)
>> >
>> > Note that object 2 has a dispose method but how do I dispose of it
>> > unless
>> > I
>> > do the following:
>> >
>> > dim myvar as new object1
>> > dim mydisposableobject as new object 2
>> > object1.dosomethingmethod(mydisposableobject )
>> > myotherobject.Dispose
>> >
>> >
>> > --
>> > Dennis in Houston
>>
>>
>>


Nov 21 '05 #6

P: n/a
To be fair.. Not disposing of some objects is perfectly ok because the CG
will get 'em in the end. Often though, and this is particularly true for
GDI+ graphics, a good preemptive Dispose is good practice as can be forcing
GC.

A lot of MSDN examples don't include the dispose because they don't need to
confuse the issue with such trivialities in a 5 line example. For the
purpose of that example this is fine.

The technique will come back to bite you later however and it's necessary to
be aware of the implications of disposing or not.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:7B**********************************@microsof t.com...
What! Microsoft Wrong...I thought they were perfect!

"Bob Powell [MVP]" wrote:
>>lots of examples in MDSN.


Yes.. sloppy lazy and often wrong..

I guess if you do a lot of that sort of thing you can try to convert the
object to IDisposable and dispose of it if it succeeds.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:FF**********************************@microsof t.com...
>I thought so. I see lots of examples in MSDN that use the first code so
>I
> guess they don't dispose of the objects and leave it to the GC.
>
> "Scott M." wrote:
>
>> Your second bit of code is your solution.
>>
>> "Dennis" <De****@discussions.microsoft.com> wrote in message
>> news:1F**********************************@microsof t.com...
>> > Ok, I'm trying to dispose of every object that I create that has a
>> > dispose
>> > method based on advice from this newsgroup. However, I'm not sure
>> > how
>> > to
>> > dispose of the following object that was created inside a method
>> > call.
>> >
>> > dim myvar as new object1
>> > object1.dosomethingmethod(new object2)
>> >
>> > Note that object 2 has a dispose method but how do I dispose of it
>> > unless
>> > I
>> > do the following:
>> >
>> > dim myvar as new object1
>> > dim mydisposableobject as new object 2
>> > object1.dosomethingmethod(mydisposableobject )
>> > myotherobject.Dispose
>> >
>> >
>> > --
>> > Dennis in Houston
>>
>>
>>


Nov 21 '05 #7

P: n/a
Bob,
a good preemptive Dispose is good practice as can be forcing GC. From what I've read forcing a GC most of the time will do more harm then
good...

http://blogs.msdn.com/ricom/archive/...29/271829.aspx

http://blogs.msdn.com/ricom/archive/.../02/40780.aspx

I do however agree that a good preemptive Dispose is good practice...

Hope this helps
Jay

Jay
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... To be fair.. Not disposing of some objects is perfectly ok because the CG
will get 'em in the end. Often though, and this is particularly true for
GDI+ graphics, a good preemptive Dispose is good practice as can be
forcing GC.

A lot of MSDN examples don't include the dispose because they don't need
to confuse the issue with such trivialities in a 5 line example. For the
purpose of that example this is fine.

The technique will come back to bite you later however and it's necessary
to be aware of the implications of disposing or not.

--
Bob Powell [MVP]
Visual C#, System.Drawing

<<snip>>
Nov 21 '05 #8

P: n/a
Whether or not you dispose an object doesn't have any affect on what the GC
will or won't do. Dispose is just a method that the class designer creates
and places code to clean up any unmanaged resources that the class may use.
GC is a separate issue.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:FF**********************************@microsof t.com...
I thought so. I see lots of examples in MSDN that use the first code so I
guess they don't dispose of the objects and leave it to the GC.

"Scott M." wrote:
Your second bit of code is your solution.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:1F**********************************@microsof t.com...
> Ok, I'm trying to dispose of every object that I create that has a
> dispose
> method based on advice from this newsgroup. However, I'm not sure how
> to
> dispose of the following object that was created inside a method call.
>
> dim myvar as new object1
> object1.dosomethingmethod(new object2)
>
> Note that object 2 has a dispose method but how do I dispose of it
> unless
> I
> do the following:
>
> dim myvar as new object1
> dim mydisposableobject as new object 2
> object1.dosomethingmethod(mydisposableobject )
> myotherobject.Dispose
>
>
> --
> Dennis in Houston


Nov 21 '05 #9

P: n/a
Yes, forcing a GC.Collect is general NOT a good idea for several reasons.

First, you may not need memory freed up at the time you call GC.Collect and
so the CPU cycles you use cleaning up memory actually may cause you
application to run slower than normal.

Second, when you call GC.Collect, the GC runs in the same thread as your
application and potentially causes you application to run slower than
normal.

The whole point of Garbage Collection is to allow the GC to collect as it
deems necessary. As soon as you intervene in that, you will most likely
make the process run less efficiently.

-Scott

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:e5****************@TK2MSFTNGP12.phx.gbl...
Bob,
a good preemptive Dispose is good practice as can be forcing GC.

From what I've read forcing a GC most of the time will do more harm then
good...

http://blogs.msdn.com/ricom/archive/...29/271829.aspx

http://blogs.msdn.com/ricom/archive/.../02/40780.aspx

I do however agree that a good preemptive Dispose is good practice...

Hope this helps
Jay

Jay
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
To be fair.. Not disposing of some objects is perfectly ok because the CG
will get 'em in the end. Often though, and this is particularly true for
GDI+ graphics, a good preemptive Dispose is good practice as can be
forcing GC.

A lot of MSDN examples don't include the dispose because they don't need
to confuse the issue with such trivialities in a 5 line example. For the
purpose of that example this is fine.

The technique will come back to bite you later however and it's necessary
to be aware of the implications of disposing or not.

--
Bob Powell [MVP]
Visual C#, System.Drawing

<<snip>>

Nov 21 '05 #10

P: n/a
JD
That depends if the class design follows the IDisposable pattern where the
Finalize method is overriden also. Notice in the IDisposable pattern if a
call to Dispose is made, a call to GC.SuppressFinalize is also called. This
will prevent object from being placed on the Finalization queue and will
prevent the object from going through an additional garbage collection. Look
at "Implementing a Dispose Method" in the MSDN documentation.
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Whether or not you dispose an object doesn't have any affect on what the GC will or won't do. Dispose is just a method that the class designer creates and places code to clean up any unmanaged resources that the class may use. GC is a separate issue.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:FF**********************************@microsof t.com...
I thought so. I see lots of examples in MSDN that use the first code so I guess they don't dispose of the objects and leave it to the GC.

"Scott M." wrote:
Your second bit of code is your solution.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:1F**********************************@microsof t.com...
> Ok, I'm trying to dispose of every object that I create that has a
> dispose
> method based on advice from this newsgroup. However, I'm not sure how > to
> dispose of the following object that was created inside a method call. >
> dim myvar as new object1
> object1.dosomethingmethod(new object2)
>
> Note that object 2 has a dispose method but how do I dispose of it
> unless
> I
> do the following:
>
> dim myvar as new object1
> dim mydisposableobject as new object 2
> object1.dosomethingmethod(mydisposableobject )
> myotherobject.Dispose
>
>
> --
> Dennis in Houston


Nov 21 '05 #11

P: n/a
Dennis,

"Dennis" <De****@discussions.microsoft.com> schrieb:
Ok, I'm trying to dispose of every object that I create that has a dispose
method based on advice from this newsgroup. However, I'm not sure how to
dispose of the following object that was created inside a method call.

dim myvar as new object1
object1.dosomethingmethod(new object2)

Note that object 2 has a dispose method but how do I dispose of it unless
I
do the following:

dim myvar as new object1
dim mydisposableobject as new object 2
object1.dosomethingmethod(mydisposableobject )
myotherobject.Dispose


If the class has a 'Dispose' method, call this method when you don't need
the object any more in order to release unmanaged resources (file handles,
window handles, etc.) occupied by the instance. The second snippet shows
the preferred way, which is calling 'Dispose'. Note that the GC will
automatically dispose the object when finalizing it. However, by calling
'Dispose' you can reduce the number of unmanaged ressources, which is very
important if there is only a limited number of such resources.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #12

P: n/a
Bob,
a good preemptive Dispose is good practice as can be forcing GC. From what I've read forcing a GC most of the time will do more harm then
good...

http://blogs.msdn.com/ricom/archive/...29/271829.aspx

http://blogs.msdn.com/ricom/archive/.../02/40780.aspx

I do however agree that a good preemptive Dispose is good practice...

Hope this helps
Jay

Jay
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... To be fair.. Not disposing of some objects is perfectly ok because the CG
will get 'em in the end. Often though, and this is particularly true for
GDI+ graphics, a good preemptive Dispose is good practice as can be
forcing GC.

A lot of MSDN examples don't include the dispose because they don't need
to confuse the issue with such trivialities in a 5 line example. For the
purpose of that example this is fine.

The technique will come back to bite you later however and it's necessary
to be aware of the implications of disposing or not.

--
Bob Powell [MVP]
Visual C#, System.Drawing

<<snip>>
Nov 21 '05 #13

P: n/a
Whether or not you dispose an object doesn't have any affect on what the GC
will or won't do. Dispose is just a method that the class designer creates
and places code to clean up any unmanaged resources that the class may use.
GC is a separate issue.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:FF**********************************@microsof t.com...
I thought so. I see lots of examples in MSDN that use the first code so I
guess they don't dispose of the objects and leave it to the GC.

"Scott M." wrote:
Your second bit of code is your solution.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:1F**********************************@microsof t.com...
> Ok, I'm trying to dispose of every object that I create that has a
> dispose
> method based on advice from this newsgroup. However, I'm not sure how
> to
> dispose of the following object that was created inside a method call.
>
> dim myvar as new object1
> object1.dosomethingmethod(new object2)
>
> Note that object 2 has a dispose method but how do I dispose of it
> unless
> I
> do the following:
>
> dim myvar as new object1
> dim mydisposableobject as new object 2
> object1.dosomethingmethod(mydisposableobject )
> myotherobject.Dispose
>
>
> --
> Dennis in Houston


Nov 21 '05 #14

P: n/a
Yes, forcing a GC.Collect is general NOT a good idea for several reasons.

First, you may not need memory freed up at the time you call GC.Collect and
so the CPU cycles you use cleaning up memory actually may cause you
application to run slower than normal.

Second, when you call GC.Collect, the GC runs in the same thread as your
application and potentially causes you application to run slower than
normal.

The whole point of Garbage Collection is to allow the GC to collect as it
deems necessary. As soon as you intervene in that, you will most likely
make the process run less efficiently.

-Scott

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:e5****************@TK2MSFTNGP12.phx.gbl...
Bob,
a good preemptive Dispose is good practice as can be forcing GC.

From what I've read forcing a GC most of the time will do more harm then
good...

http://blogs.msdn.com/ricom/archive/...29/271829.aspx

http://blogs.msdn.com/ricom/archive/.../02/40780.aspx

I do however agree that a good preemptive Dispose is good practice...

Hope this helps
Jay

Jay
"Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
To be fair.. Not disposing of some objects is perfectly ok because the CG
will get 'em in the end. Often though, and this is particularly true for
GDI+ graphics, a good preemptive Dispose is good practice as can be
forcing GC.

A lot of MSDN examples don't include the dispose because they don't need
to confuse the issue with such trivialities in a 5 line example. For the
purpose of that example this is fine.

The technique will come back to bite you later however and it's necessary
to be aware of the implications of disposing or not.

--
Bob Powell [MVP]
Visual C#, System.Drawing

<<snip>>

Nov 21 '05 #15

P: n/a
JD
That depends if the class design follows the IDisposable pattern where the
Finalize method is overriden also. Notice in the IDisposable pattern if a
call to Dispose is made, a call to GC.SuppressFinalize is also called. This
will prevent object from being placed on the Finalization queue and will
prevent the object from going through an additional garbage collection. Look
at "Implementing a Dispose Method" in the MSDN documentation.
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Whether or not you dispose an object doesn't have any affect on what the GC will or won't do. Dispose is just a method that the class designer creates and places code to clean up any unmanaged resources that the class may use. GC is a separate issue.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:FF**********************************@microsof t.com...
I thought so. I see lots of examples in MSDN that use the first code so I guess they don't dispose of the objects and leave it to the GC.

"Scott M." wrote:
Your second bit of code is your solution.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:1F**********************************@microsof t.com...
> Ok, I'm trying to dispose of every object that I create that has a
> dispose
> method based on advice from this newsgroup. However, I'm not sure how > to
> dispose of the following object that was created inside a method call. >
> dim myvar as new object1
> object1.dosomethingmethod(new object2)
>
> Note that object 2 has a dispose method but how do I dispose of it
> unless
> I
> do the following:
>
> dim myvar as new object1
> dim mydisposableobject as new object 2
> object1.dosomethingmethod(mydisposableobject )
> myotherobject.Dispose
>
>
> --
> Dennis in Houston


Nov 21 '05 #16

P: n/a
Dennis,

"Dennis" <De****@discussions.microsoft.com> schrieb:
Ok, I'm trying to dispose of every object that I create that has a dispose
method based on advice from this newsgroup. However, I'm not sure how to
dispose of the following object that was created inside a method call.

dim myvar as new object1
object1.dosomethingmethod(new object2)

Note that object 2 has a dispose method but how do I dispose of it unless
I
do the following:

dim myvar as new object1
dim mydisposableobject as new object 2
object1.dosomethingmethod(mydisposableobject )
myotherobject.Dispose


If the class has a 'Dispose' method, call this method when you don't need
the object any more in order to release unmanaged resources (file handles,
window handles, etc.) occupied by the instance. The second snippet shows
the preferred way, which is calling 'Dispose'. Note that the GC will
automatically dispose the object when finalizing it. However, by calling
'Dispose' you can reduce the number of unmanaged ressources, which is very
important if there is only a limited number of such resources.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #17

P: n/a
Dennis,

When you inherit from Components than there is already Idispose implemented
in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to do
nothing because it is done by the base class when that class goes out of
scope. Therefore I inherit from components when I make a class from which I
have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor
Nov 21 '05 #18

P: n/a
Dennis,

When you inherit from Components than there is already Idispose implemented
in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to do
nothing because it is done by the base class when that class goes out of
scope. Therefore I inherit from components when I make a class from which I
have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor
Nov 21 '05 #19

P: n/a
Thanks to all. I am beginning to understand a little of what the dispose is
all about and all this discussion certainly helps me and I think a lot of
people using VB.Net. I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have a
dispose method, don't worry about it!"

"Cor Ligthert" wrote:
Dennis,

When you inherit from Components than there is already Idispose implemented
in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to do
nothing because it is done by the base class when that class goes out of
scope. Therefore I inherit from components when I make a class from which I
have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor

Nov 21 '05 #20

P: n/a
Thanks to all. I am beginning to understand a little of what the dispose is
all about and all this discussion certainly helps me and I think a lot of
people using VB.Net. I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have a
dispose method, don't worry about it!"

"Cor Ligthert" wrote:
Dennis,

When you inherit from Components than there is already Idispose implemented
in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to do
nothing because it is done by the base class when that class goes out of
scope. Therefore I inherit from components when I make a class from which I
have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor

Nov 21 '05 #21

P: n/a
Dennis,
Thanks to all. I am beginning to understand a little of what the dispose
is
all about and all this discussion certainly helps me and I think a lot of
people using VB.Net. I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!"

While that is in my opinion not the good method. It is in a lot of cases
exactly opostite, when it has no dispose method, create it when it is using
an unmanaged resource.

When you read my message than you see that a lot of classes have dispose,
just because they inherits form component. That is not a reason to call all
the members in that which have that as well all individual.

Cor
Nov 21 '05 #22

P: n/a
Dennis,
Thanks to all. I am beginning to understand a little of what the dispose
is
all about and all this discussion certainly helps me and I think a lot of
people using VB.Net. I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!"

While that is in my opinion not the good method. It is in a lot of cases
exactly opostite, when it has no dispose method, create it when it is using
an unmanaged resource.

When you read my message than you see that a lot of classes have dispose,
just because they inherits form component. That is not a reason to call all
the members in that which have that as well all individual.

Cor
Nov 21 '05 #23

P: n/a
How am I to know if objects such as OleDbDataAdaptor use unmanaged resources
and whether or not I should call it's dispose method?

"Cor Ligthert" wrote:
Dennis,
Thanks to all. I am beginning to understand a little of what the dispose
is
all about and all this discussion certainly helps me and I think a lot of
people using VB.Net. I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!"

While that is in my opinion not the good method. It is in a lot of cases
exactly opostite, when it has no dispose method, create it when it is using
an unmanaged resource.

When you read my message than you see that a lot of classes have dispose,
just because they inherits form component. That is not a reason to call all
the members in that which have that as well all individual.

Cor

Nov 21 '05 #24

P: n/a
How am I to know if objects such as OleDbDataAdaptor use unmanaged resources
and whether or not I should call it's dispose method?

"Cor Ligthert" wrote:
Dennis,
Thanks to all. I am beginning to understand a little of what the dispose
is
all about and all this discussion certainly helps me and I think a lot of
people using VB.Net. I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!"

While that is in my opinion not the good method. It is in a lot of cases
exactly opostite, when it has no dispose method, create it when it is using
an unmanaged resource.

When you read my message than you see that a lot of classes have dispose,
just because they inherits form component. That is not a reason to call all
the members in that which have that as well all individual.

Cor

Nov 21 '05 #25

P: n/a
Generally, you can look a the big picture of what the class does. With any
of the data connectivity classes (dataadapters, datareaders, connections),
calling dispose is a good idea because the basic job of these classes is to
connect to unmanaged resources.

Classes that help you get to resources "outside" of the CLR's domain are
good classes to dispose. But I wouldn't worry about disposing a label, for
example.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:F4**********************************@microsof t.com...
How am I to know if objects such as OleDbDataAdaptor use unmanaged
resources
and whether or not I should call it's dispose method?

"Cor Ligthert" wrote:
Dennis,
> Thanks to all. I am beginning to understand a little of what the
> dispose
> is
> all about and all this discussion certainly helps me and I think a lot
> of
> people using VB.Net. I have implemented the practice of "If it's got a
> dispose method, then call it when I'm thru with it and if it doesn't
> have
> a
> dispose method, don't worry about it!"
>

While that is in my opinion not the good method. It is in a lot of cases
exactly opostite, when it has no dispose method, create it when it is
using
an unmanaged resource.

When you read my message than you see that a lot of classes have dispose,
just because they inherits form component. That is not a reason to call
all
the members in that which have that as well all individual.

Cor

Nov 21 '05 #26

P: n/a
Generally, you can look a the big picture of what the class does. With any
of the data connectivity classes (dataadapters, datareaders, connections),
calling dispose is a good idea because the basic job of these classes is to
connect to unmanaged resources.

Classes that help you get to resources "outside" of the CLR's domain are
good classes to dispose. But I wouldn't worry about disposing a label, for
example.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:F4**********************************@microsof t.com...
How am I to know if objects such as OleDbDataAdaptor use unmanaged
resources
and whether or not I should call it's dispose method?

"Cor Ligthert" wrote:
Dennis,
> Thanks to all. I am beginning to understand a little of what the
> dispose
> is
> all about and all this discussion certainly helps me and I think a lot
> of
> people using VB.Net. I have implemented the practice of "If it's got a
> dispose method, then call it when I'm thru with it and if it doesn't
> have
> a
> dispose method, don't worry about it!"
>

While that is in my opinion not the good method. It is in a lot of cases
exactly opostite, when it has no dispose method, create it when it is
using
an unmanaged resource.

When you read my message than you see that a lot of classes have dispose,
just because they inherits form component. That is not a reason to call
all
the members in that which have that as well all individual.

Cor

Nov 21 '05 #27

P: n/a
Dennis,

There is no need to dispose any object of system.data.

I have written a while that the exception on this is the connection, that
is used for the connection pooling what was consequently told by Angel in
the AdoNet newsgroup and that was done something with the fysical connection
string (not the code) in a kind of overriden function from dispose.

Because this message below in that newsgroup (it is not the first) I become
confused again however keep that dispose for the connection string. The
other objects does not need a dispose. There the dispose is only because the
method is inherited from components from which all system.data classes
inherits.

http://groups-beta.google.com/group/...11c0671640ad38

I hope this give some idea's

Cor
Nov 21 '05 #28

P: n/a
Dennis,

There is no need to dispose any object of system.data.

I have written a while that the exception on this is the connection, that
is used for the connection pooling what was consequently told by Angel in
the AdoNet newsgroup and that was done something with the fysical connection
string (not the code) in a kind of overriden function from dispose.

Because this message below in that newsgroup (it is not the first) I become
confused again however keep that dispose for the connection string. The
other objects does not need a dispose. There the dispose is only because the
method is inherited from components from which all system.data classes
inherits.

http://groups-beta.google.com/group/...11c0671640ad38

I hope this give some idea's

Cor
Nov 21 '05 #29

P: n/a
I'm not so sure about that Cor. I have read many articles and seen many
posts that suggest that the DataAdapter, DataReader and Connection objects
SHOULD be disposed.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Dennis,

There is no need to dispose any object of system.data.

I have written a while that the exception on this is the connection, that
is used for the connection pooling what was consequently told by Angel in
the AdoNet newsgroup and that was done something with the fysical
connection string (not the code) in a kind of overriden function from
dispose.

Because this message below in that newsgroup (it is not the first) I
become confused again however keep that dispose for the connection string.
The other objects does not need a dispose. There the dispose is only
because the method is inherited from components from which all system.data
classes inherits.

http://groups-beta.google.com/group/...11c0671640ad38

I hope this give some idea's

Cor

Nov 21 '05 #30

P: n/a
I'm not so sure about that Cor. I have read many articles and seen many
posts that suggest that the DataAdapter, DataReader and Connection objects
SHOULD be disposed.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Dennis,

There is no need to dispose any object of system.data.

I have written a while that the exception on this is the connection, that
is used for the connection pooling what was consequently told by Angel in
the AdoNet newsgroup and that was done something with the fysical
connection string (not the code) in a kind of overriden function from
dispose.

Because this message below in that newsgroup (it is not the first) I
become confused again however keep that dispose for the connection string.
The other objects does not need a dispose. There the dispose is only
because the method is inherited from components from which all system.data
classes inherits.

http://groups-beta.google.com/group/...11c0671640ad38

I hope this give some idea's

Cor

Nov 21 '05 #31

P: n/a
If I understand Dispose() correctly, it simply forces the .NET framework to
mark an object for Garbage Collection. As I look at the "Windows Forms
Designer generated" Dispose() method of a Form, it is appears that the Form
itself performs Dispose() on all the Form's components, which if I'm not
mistaken, would include labels, etc.

As I understand it, Dispose() does not force a Garbage Collection, so that
should not be an issue. Is there any real benefit to *not* calling
Dispose() on objects that expose it once you know that they are no longer
needed (such as a SqlCommand), or is there a complex matrix of rules for
when and when not to use Dispose() that should be referenced every time you
create a new object?

"Cor Ligthert" <no************@planet.nl> wrote in message
news:ul*************@TK2MSFTNGP12.phx.gbl...
Dennis,

When you inherit from Components than there is already Idispose
implemented in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to do
nothing because it is done by the base class when that class goes out of
scope. Therefore I inherit from components when I make a class from which
I have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor

Nov 21 '05 #32

P: n/a
If I understand Dispose() correctly, it simply forces the .NET framework to
mark an object for Garbage Collection. As I look at the "Windows Forms
Designer generated" Dispose() method of a Form, it is appears that the Form
itself performs Dispose() on all the Form's components, which if I'm not
mistaken, would include labels, etc.

As I understand it, Dispose() does not force a Garbage Collection, so that
should not be an issue. Is there any real benefit to *not* calling
Dispose() on objects that expose it once you know that they are no longer
needed (such as a SqlCommand), or is there a complex matrix of rules for
when and when not to use Dispose() that should be referenced every time you
create a new object?

"Cor Ligthert" <no************@planet.nl> wrote in message
news:ul*************@TK2MSFTNGP12.phx.gbl...
Dennis,

When you inherit from Components than there is already Idispose
implemented in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to do
nothing because it is done by the base class when that class goes out of
scope. Therefore I inherit from components when I make a class from which
I have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor

Nov 21 '05 #33

P: n/a
Cor,
There is no need to dispose any object of system.data. Where do you get that in the link you gave???

If anything the link you gave says you need to call Dispose (or Close).

Your statement may be (partially) true for the System.Data namespace itself,
however it is not even close to true for (most of) System.Data.Odbc,
System.Data.OleDb, System.Data.SqlClient, and System.Data.OracleClient! As
they all contain classes that deal with "external" (aka unmanaged) resource.

Hope this helps
Jay

"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... Dennis,

There is no need to dispose any object of system.data.

I have written a while that the exception on this is the connection, that
is used for the connection pooling what was consequently told by Angel in
the AdoNet newsgroup and that was done something with the fysical
connection string (not the code) in a kind of overriden function from
dispose.

Because this message below in that newsgroup (it is not the first) I
become confused again however keep that dispose for the connection string.
The other objects does not need a dispose. There the dispose is only
because the method is inherited from components from which all system.data
classes inherits.

http://groups-beta.google.com/group/...11c0671640ad38

I hope this give some idea's

Cor

Nov 21 '05 #34

P: n/a
Cor,
There is no need to dispose any object of system.data. Where do you get that in the link you gave???

If anything the link you gave says you need to call Dispose (or Close).

Your statement may be (partially) true for the System.Data namespace itself,
however it is not even close to true for (most of) System.Data.Odbc,
System.Data.OleDb, System.Data.SqlClient, and System.Data.OracleClient! As
they all contain classes that deal with "external" (aka unmanaged) resource.

Hope this helps
Jay

"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... Dennis,

There is no need to dispose any object of system.data.

I have written a while that the exception on this is the connection, that
is used for the connection pooling what was consequently told by Angel in
the AdoNet newsgroup and that was done something with the fysical
connection string (not the code) in a kind of overriden function from
dispose.

Because this message below in that newsgroup (it is not the first) I
become confused again however keep that dispose for the connection string.
The other objects does not need a dispose. There the dispose is only
because the method is inherited from components from which all system.data
classes inherits.

http://groups-beta.google.com/group/...11c0671640ad38

I hope this give some idea's

Cor

Nov 21 '05 #35

P: n/a
Dennis,
I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!" Without "knowing" for certain that IMHO is the "best" practice.

The "better safe then sorry" pattern. :-)

Hope this helps
Jay
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:8E**********************************@microsof t.com... Thanks to all. I am beginning to understand a little of what the dispose
is
all about and all this discussion certainly helps me and I think a lot of
people using VB.Net. I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!"

"Cor Ligthert" wrote:
Dennis,

When you inherit from Components than there is already Idispose
implemented
in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to
do
nothing because it is done by the base class when that class goes out of
scope. Therefore I inherit from components when I make a class from which
I
have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor

Nov 21 '05 #36

P: n/a
Dennis,
I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!" Without "knowing" for certain that IMHO is the "best" practice.

The "better safe then sorry" pattern. :-)

Hope this helps
Jay
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:8E**********************************@microsof t.com... Thanks to all. I am beginning to understand a little of what the dispose
is
all about and all this discussion certainly helps me and I think a lot of
people using VB.Net. I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!"

"Cor Ligthert" wrote:
Dennis,

When you inherit from Components than there is already Idispose
implemented
in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to
do
nothing because it is done by the base class when that class goes out of
scope. Therefore I inherit from components when I make a class from which
I
have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor

Nov 21 '05 #37

P: n/a
> If I understand Dispose() correctly, it simply forces the .NET framework
to mark an object for Garbage Collection.
Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.
As I look at the "Windows Forms Designer generated" Dispose() method of a
Form, it is appears that the Form itself performs Dispose() on all the
Form's components, which if I'm not mistaken, would include labels, etc.
Correct, but since the designer has no idea what kind of controls you'll be
putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).
As I understand it, Dispose() does not force a Garbage Collection, so that
should not be an issue.
Correct.
Is there any real benefit to *not* calling Dispose() on objects that
expose it once you know that they are no longer needed (such as a
SqlCommand), or is there a complex matrix of rules for when and when not
to use Dispose() that should be referenced every time you create a new
object?
Calling Dispose on a label wouldn't *hurt* anything, but it would cause your
application to perform additional tasks that may not be needed. So, it
could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.


"Cor Ligthert" <no************@planet.nl> wrote in message
news:ul*************@TK2MSFTNGP12.phx.gbl...
Dennis,

When you inherit from Components than there is already Idispose
implemented in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to
do nothing because it is done by the base class when that class goes out
of scope. Therefore I inherit from components when I make a class from
which I have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor


Nov 21 '05 #38

P: n/a
> If I understand Dispose() correctly, it simply forces the .NET framework
to mark an object for Garbage Collection.
Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.
As I look at the "Windows Forms Designer generated" Dispose() method of a
Form, it is appears that the Form itself performs Dispose() on all the
Form's components, which if I'm not mistaken, would include labels, etc.
Correct, but since the designer has no idea what kind of controls you'll be
putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).
As I understand it, Dispose() does not force a Garbage Collection, so that
should not be an issue.
Correct.
Is there any real benefit to *not* calling Dispose() on objects that
expose it once you know that they are no longer needed (such as a
SqlCommand), or is there a complex matrix of rules for when and when not
to use Dispose() that should be referenced every time you create a new
object?
Calling Dispose on a label wouldn't *hurt* anything, but it would cause your
application to perform additional tasks that may not be needed. So, it
could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.


"Cor Ligthert" <no************@planet.nl> wrote in message
news:ul*************@TK2MSFTNGP12.phx.gbl...
Dennis,

When you inherit from Components than there is already Idispose
implemented in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to
do nothing because it is done by the base class when that class goes out
of scope. Therefore I inherit from components when I make a class from
which I have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor


Nov 21 '05 #39

P: n/a
Jay,

What has it for sense to dispose every individual part of a class when the
base class does the dispose?
Your statement may be (partially) true for the System.Data namespace
itself, however it is not even close to true for (most of)
System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and
System.Data.OracleClient! As they all contain classes that deal with
"external" (aka unmanaged) resource.


Do you mean that I understand this page wrong?

http://msdn.microsoft.com/library/de...erarchy.aspCor

Nov 21 '05 #40

P: n/a
Jay,

What has it for sense to dispose every individual part of a class when the
base class does the dispose?
Your statement may be (partially) true for the System.Data namespace
itself, however it is not even close to true for (most of)
System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and
System.Data.OracleClient! As they all contain classes that deal with
"external" (aka unmanaged) resource.


Do you mean that I understand this page wrong?

http://msdn.microsoft.com/library/de...erarchy.aspCor

Nov 21 '05 #41

P: n/a
This is the thrid or fourth different question I've posed on this newsgroup
about dispose and really enjoy the "confusion". If Microsoft is listening,
then they should step up and "in plan English" explain when to dispose and
when not to. They give hints and sometimes even state that something needs
to be disposed in their MSDN help but I sure wish they'd put this like in the
header of the help sheets such as "Dispose needed - Yes/No"

"Scott M." wrote:
If I understand Dispose() correctly, it simply forces the .NET framework
to mark an object for Garbage Collection.


Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.
As I look at the "Windows Forms Designer generated" Dispose() method of a
Form, it is appears that the Form itself performs Dispose() on all the
Form's components, which if I'm not mistaken, would include labels, etc.


Correct, but since the designer has no idea what kind of controls you'll be
putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).
As I understand it, Dispose() does not force a Garbage Collection, so that
should not be an issue.


Correct.
Is there any real benefit to *not* calling Dispose() on objects that
expose it once you know that they are no longer needed (such as a
SqlCommand), or is there a complex matrix of rules for when and when not
to use Dispose() that should be referenced every time you create a new
object?


Calling Dispose on a label wouldn't *hurt* anything, but it would cause your
application to perform additional tasks that may not be needed. So, it
could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.


"Cor Ligthert" <no************@planet.nl> wrote in message
news:ul*************@TK2MSFTNGP12.phx.gbl...
Dennis,

When you inherit from Components than there is already Idispose
implemented in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to
do nothing because it is done by the base class when that class goes out
of scope. Therefore I inherit from components when I make a class from
which I have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor



Nov 21 '05 #44

P: n/a
This is the thrid or fourth different question I've posed on this newsgroup
about dispose and really enjoy the "confusion". If Microsoft is listening,
then they should step up and "in plan English" explain when to dispose and
when not to. They give hints and sometimes even state that something needs
to be disposed in their MSDN help but I sure wish they'd put this like in the
header of the help sheets such as "Dispose needed - Yes/No"

"Scott M." wrote:
If I understand Dispose() correctly, it simply forces the .NET framework
to mark an object for Garbage Collection.


Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.
As I look at the "Windows Forms Designer generated" Dispose() method of a
Form, it is appears that the Form itself performs Dispose() on all the
Form's components, which if I'm not mistaken, would include labels, etc.


Correct, but since the designer has no idea what kind of controls you'll be
putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).
As I understand it, Dispose() does not force a Garbage Collection, so that
should not be an issue.


Correct.
Is there any real benefit to *not* calling Dispose() on objects that
expose it once you know that they are no longer needed (such as a
SqlCommand), or is there a complex matrix of rules for when and when not
to use Dispose() that should be referenced every time you create a new
object?


Calling Dispose on a label wouldn't *hurt* anything, but it would cause your
application to perform additional tasks that may not be needed. So, it
could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.


"Cor Ligthert" <no************@planet.nl> wrote in message
news:ul*************@TK2MSFTNGP12.phx.gbl...
Dennis,

When you inherit from Components than there is already Idispose
implemented in the base class. (By instance all classes in Sytem.Data and
System.Windows.Forms.Control inherit from Components) You just have to
do nothing because it is done by the base class when that class goes out
of scope. Therefore I inherit from components when I make a class from
which I have slightly the idea that it has unmanaged resources in it.

http://search.microsoft.com/search/r...&c=0&s=1&swc=0

IComponent implements IDisposable for when you are searching that.

I hope this helps,

Cor



Nov 21 '05 #45

P: n/a
"Scott M." <s-***@nospam.nospam> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl...
If I understand Dispose() correctly, it simply forces the .NET framework
to mark an object for Garbage Collection.
Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.


What does Dispose() do exactly?
As I look at the "Windows Forms Designer generated" Dispose() method of a
Form, it is appears that the Form itself performs Dispose() on all the
Form's components, which if I'm not mistaken, would include labels, etc.


Correct, but since the designer has no idea what kind of controls you'll
be putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).


Are you advocating getting rid of the Windows Forms Designer generated code
as unnecessary? Or are you saying that "better safe than sorry" only
applies to Designer generated code and not to code created by a programmer?
Is there any real benefit to *not* calling Dispose() on objects that
expose it once you know that they are no longer needed (such as a
SqlCommand), or is there a complex matrix of rules for when and when not
to use Dispose() that should be referenced every time you create a new
object?


Calling Dispose on a label wouldn't *hurt* anything, but it would cause
your application to perform additional tasks that may not be needed. So,
it could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.


So, logically:

1. Calling Dispose() on a label wouldn't *hurt* anything;
2. Calling Dispose() on a label would cause your application to perform
additional tasks that *may* not be needed
3. Calling Dispose() on a label *could conceivably* slow down an
application
4. Therefore, *don't* call Dispose() on SqlCommands

Does that about sum up the train of thought here?

If the Matrix of objects on which you should call Dispose() versus those on
which you should not call Dispose() is as convoluted as this logic, how do
programmers get anything done without spending cross-referencing which
objects should and should not be Disposed of. How in the world do you write
even the simplest of programs without spending hours worrying about this
low-level garbage?
Nov 21 '05 #46

P: n/a
"Scott M." <s-***@nospam.nospam> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl...
If I understand Dispose() correctly, it simply forces the .NET framework
to mark an object for Garbage Collection.
Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.


What does Dispose() do exactly?
As I look at the "Windows Forms Designer generated" Dispose() method of a
Form, it is appears that the Form itself performs Dispose() on all the
Form's components, which if I'm not mistaken, would include labels, etc.


Correct, but since the designer has no idea what kind of controls you'll
be putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).


Are you advocating getting rid of the Windows Forms Designer generated code
as unnecessary? Or are you saying that "better safe than sorry" only
applies to Designer generated code and not to code created by a programmer?
Is there any real benefit to *not* calling Dispose() on objects that
expose it once you know that they are no longer needed (such as a
SqlCommand), or is there a complex matrix of rules for when and when not
to use Dispose() that should be referenced every time you create a new
object?


Calling Dispose on a label wouldn't *hurt* anything, but it would cause
your application to perform additional tasks that may not be needed. So,
it could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.


So, logically:

1. Calling Dispose() on a label wouldn't *hurt* anything;
2. Calling Dispose() on a label would cause your application to perform
additional tasks that *may* not be needed
3. Calling Dispose() on a label *could conceivably* slow down an
application
4. Therefore, *don't* call Dispose() on SqlCommands

Does that about sum up the train of thought here?

If the Matrix of objects on which you should call Dispose() versus those on
which you should not call Dispose() is as convoluted as this logic, how do
programmers get anything done without spending cross-referencing which
objects should and should not be Disposed of. How in the world do you write
even the simplest of programs without spending hours worrying about this
low-level garbage?
Nov 21 '05 #47

P: n/a
I think your link sums it all up Perfectly:

"Page Cannot Be Found
We apologize for the inconvenience, but the page you are seeking cannot be
found in this location."

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uF**************@tk2msftngp13.phx.gbl...
Jay,

What has it for sense to dispose every individual part of a class when the
base class does the dispose?
Your statement may be (partially) true for the System.Data namespace
itself, however it is not even close to true for (most of)
System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and
System.Data.OracleClient! As they all contain classes that deal with
"external" (aka unmanaged) resource.


Do you mean that I understand this page wrong?

http://msdn.microsoft.com/library/de...erarchy.aspCor

Nov 21 '05 #48

P: n/a
I think your link sums it all up Perfectly:

"Page Cannot Be Found
We apologize for the inconvenience, but the page you are seeking cannot be
found in this location."

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uF**************@tk2msftngp13.phx.gbl...
Jay,

What has it for sense to dispose every individual part of a class when the
base class does the dispose?
Your statement may be (partially) true for the System.Data namespace
itself, however it is not even close to true for (most of)
System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and
System.Data.OracleClient! As they all contain classes that deal with
"external" (aka unmanaged) resource.


Do you mean that I understand this page wrong?

http://msdn.microsoft.com/library/de...erarchy.aspCor

Nov 21 '05 #49

P: n/a
JD
OK. Take three scenarios.

(1) Dispose is present in a class but does nothing.
(2) Dispose is present in a class and cleans up unmanaged resources.
(3) Dispose is present in a class and does some clean up logic but its all
managed code.

In the case of (1), it won't hurt to call it because the JIT will optimize
the call away. So it costs you nothing to make the call. I vote make the
call to Dispose.

In the case of (2) the class will also override the finalize method. This
logic will be called either by calling Dispose or by the finalize thread. So
calling it or not calling it doesn't hurt you either way, the call will be
made. But waiting for the finalize method to be called is a bad idea because
you are hanging onto the unmanaged resources until the finalize thread is
run and there is no guarantee when that will be, and in the case of a file
handle or database connection that can be a real bad thing. Plus if you wait
till the finalize method is called, the object goes through an additional
garbage collection. I vote make the call to Dispose.

In the case of (3) the class developer put code into the Dispose method so
people using an instance of the class will call it when they are done with
the instance of the class. This may cost you some performance but you are
heeding the advice of the class developer. Example might be, the class
registers as a listener for a global event, and calling Dispose unregisters
itself as a listener, if you don't call Dispose setting the object to
Nothing will leave it alive because a reference of the object is still
registered to the global event. This can and will be seen as a memory leak
as long as your application runs. As for the performance hit, if your
application is having performance problems I'll guarantee you the solution
won't be go through your code and remove all the calls to Dispose. I vote
make the call to Dispose.

So there you have my logic. (1) and (2) to me are a no brainer, make the
call to Dispose. As for (3) listen to the class developer, don't worry about
performance until performance problems arise, and by then you will be
profiling your application and chances are the problem won't be the calls to
Dispose.

Plus there is an additional thing you must think about and thats just
because the current version of the object's Dispose method does nothing or
the current version of the class doesn't use unmanaged resources, that
doesn't mean future versions of it will not. Making the decision of not
calling Dispose now might hurt you in the future when new versions of the
class is installed into production.


"Michael C#" <xy*@abcdef.com> wrote in message
news:ZW*****************@fe10.lga...
"Scott M." <s-***@nospam.nospam> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl...
If I understand Dispose() correctly, it simply forces the .NET framework to mark an object for Garbage Collection.
Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.


What does Dispose() do exactly?
As I look at the "Windows Forms Designer generated" Dispose() method of aForm, it is appears that the Form itself performs Dispose() on all the
Form's components, which if I'm not mistaken, would include labels, etc.


Correct, but since the designer has no idea what kind of controls you'll
be putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).


Are you advocating getting rid of the Windows Forms Designer generated

code as unnecessary? Or are you saying that "better safe than sorry" only
applies to Designer generated code and not to code created by a programmer? Is there any real benefit to *not* calling Dispose() on objects that
expose it once you know that they are no longer needed (such as a
SqlCommand), or is there a complex matrix of rules for when and when not to use Dispose() that should be referenced every time you create a new
object?
Calling Dispose on a label wouldn't *hurt* anything, but it would cause
your application to perform additional tasks that may not be needed. So, it could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.


So, logically:

1. Calling Dispose() on a label wouldn't *hurt* anything;
2. Calling Dispose() on a label would cause your application to perform
additional tasks that *may* not be needed
3. Calling Dispose() on a label *could conceivably* slow down an
application
4. Therefore, *don't* call Dispose() on SqlCommands

Does that about sum up the train of thought here?

If the Matrix of objects on which you should call Dispose() versus those

on which you should not call Dispose() is as convoluted as this logic, how do
programmers get anything done without spending cross-referencing which
objects should and should not be Disposed of. How in the world do you write even the simplest of programs without spending hours worrying about this
low-level garbage?

Nov 21 '05 #50

156 Replies

This discussion thread is closed

Replies have been disabled for this discussion.