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
156  5385 
"Scott M." <s-***@nospam.nospam> wrote in message
news:eJ**************@TK2MSFTNGP10.phx.gbl... I think you are putting words (or opinions) into my mouth when all I was
trying to do was make a point.
Point taken, an I have no need to put words "into your mouth":
"It is up to the class user to call this method [Dispose]."
My original point, as desmonstrated by the Microsoft(tm)-sponsored statement
and code previously posted, is that the Finalize method can call Dispose.
The Finalize method is called via the GC. The GC normally is not invoked by
the "class user". It *can* happen; therefore the statement is False.
"This is the whole point behind Dispose. To even imply that the GC calls
dispose (when, in many situations it won't - even through the finalizer) is
mis-leading."
I'm about to Imply, as Microsoft(tm) has done, this documented fact: The GC
can call Finalize, which *may* indeed call Dispose. There is absolutely
nothing misleading about this fact, and it is well-documented. Now, should
you count on Finalize to call dispose? Absolutely not. But the fact of the
matter is that Finalize *can* indeed call Dispose.
Anything further is fluff.
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3u6f2.vtv.df*****@woofix.local.dom... On 2005-03-21, Michael C# <xy*@yomomma.com> wrote:
After all, I tested the third option with the
SqlCommand object in this thread days ago, and still haven't received a
simple "YES" or "NO" concerning whether or not it should be Disposed of!
OK, a simple answer. Disposing a SqlCommand does absolutely nothing
except take up time. It's a no-op.
Thank you! Finally a straight answer! My next question is this: is the
optimizer smart enough to figure this out and discard the no-op? Instead I get responses concerning "Labels" and patterns of usage: ("use
it
all the time", "use it none of the time", "use it correctly")!
Imagine if you had to stop development for days each and every time you
ran
across a new class that exposed Dispose(), so that you could post a
newsgroup message and await a response - which might or might not be
forthcoming.
I see your general point here, but in practice it's not that tough. In
day-to-day programming, I pretty much deal with only four types of
objects:
Web controls, which never need to be disposed.
Forms controls, which should always be disposed.
Data library objects, and since there's only a few of them I tend to
know the ones I'm working with pretty damn well since I'm hitting the db
all day long, and so I have a pretty good sense as to whether I want to
dispose them and when.
Things that derive from Component, which generally don't need to be
disposed, but it only takes a moment to figure out if the class actually
implements a Dispose function, so in practice that's not a problem.
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?
Also, at the end you mention "it only takes a moment to figure out if the
class actually implements a Dispose function..." which takes us full circle
to the crux of the matter - some say that not everything that implements a
Dispose needs to be Disposed. The question is which Components that expose
a Dispose method need to have Dispose called on them? Alas, it's much simpler to consistently Dispose() of my
SqlCommand, SqlConnection and other objects when I'm done with them. I
would love to see a demonstration of how all the proposed research into
this
arcane trivia generates anything greater than a personal sense of
accomplishment...
I actually think avoiding the Dispose calls makes code a lot cleaner.
That may be true, but I think it may be short-term thinking. Per another
message in here, if the SqlCommand, for instance, were to be implemented
differently in the future - and the Developer suddenly recommends the use of
Dispose - you will have to re-tool your design patterns and re-work your
code.
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3u57j.vtv.df*****@woofix.local.dom... What's your point exactly? Are you implying that VS.Net *doesn't* need
to call Dispose on custom controls and components instantiated in
designers? Why not?
Well, see David, I think it goes back to the well-documented Third Rule
which states "Use Dispose() correctly"...
:)
OK, that makes more sense. You were showing the list of Component-derived
classes which require Dispose.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:uf****************@TK2MSFTNGP14.phx.gbl... Michael,
This was an answer on Jay, where he told that some classes in this list
did not derive from component.
Small correction again. That was the way I understood Jay's message
because that was in my idea the main part. I readed the unmanaged
resources part as an addition. I start to understand that his meaning
about the message was more about the unmanaged resources part.
Cor
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.
On 2005-03-22, Michael C# <xy*@abcdef.com> wrote:
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3u6f2.vtv.df*****@woofix.local.dom... On 2005-03-21, Michael C# <xy*@yomomma.com> wrote:
After all, I tested the third option with the
SqlCommand object in this thread days ago, and still haven't received a
simple "YES" or "NO" concerning whether or not it should be Disposed of!
OK, a simple answer. Disposing a SqlCommand does absolutely nothing
except take up time. It's a no-op.
Thank you! Finally a straight answer! My next question is this: is the
optimizer smart enough to figure this out and discard the no-op?
I don't see how, that's why it takes up (a little) time. There's a lock
and a few tests involved.
I see your general point here, but in practice it's not that tough. In
day-to-day programming, I pretty much deal with only four types of
objects:
Web controls, which never need to be disposed.
Forms controls, which should always be disposed.
Data library objects, and since there's only a few of them I tend to
know the ones I'm working with pretty damn well since I'm hitting the db
all day long, and so I have a pretty good sense as to whether I want to
dispose them and when.
Things that derive from Component, which generally don't need to be
disposed, but it only takes a moment to figure out if the class actually
implements a Dispose function, so in practice that's not a problem.
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?
In practice, it's really not an issue for me. I add it to components
and I know the components will be disposed for me. I realize there are
designs where this is a real issue, but so far it's just not an issue to
me.
Also, at the end you mention "it only takes a moment to figure out if the
class actually implements a Dispose function..." which takes us full circle
to the crux of the matter - some say that not everything that implements a
Dispose needs to be Disposed. The question is which Components that expose
a Dispose method need to have Dispose called on them?
I know what Component.Dispose does, and MarshallByRefComponent.Dispose, etc. So
the only issue is whether the class itself implements a needed Dispose
override, and that only takes a second to check. Alas, it's much simpler to consistently Dispose() of my
SqlCommand, SqlConnection and other objects when I'm done with them. I
would love to see a demonstration of how all the proposed research into
this
arcane trivia generates anything greater than a personal sense of
accomplishment...
I actually think avoiding the Dispose calls makes code a lot cleaner.
That may be true, but I think it may be short-term thinking. Per another
message in here, if the SqlCommand, for instance, were to be implemented
differently in the future - and the Developer suddenly recommends the use of
Dispose - you will have to re-tool your design patterns and re-work your
code.
And I do worry about that, but there's a flipside. I see a lot of code
that does a premature Dispose that only works because Dispose doesn't
really do anything. If some class I'm calling suddenly implement a
truly destructive dispose, my code might have a few temporary leaks but
that's better than simply crashing. And I do somewhat trust that decent
programmers will implement Finalize correctly.
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.
Michael, 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.
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.
As for learning the inner workings of classes in the .NET Framework, I
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#" <xy*@yomomma.com> wrote in message
news:eE***************@TK2MSFTNGP15.phx.gbl... 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".
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3ubju.fa.df*****@woofix.local.dom... On 2005-03-22, Michael C# <xy*@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?
In practice, it's really not an issue for me. I add it to components
and I know the components will be disposed for me. I realize there are
designs where this is a real issue, but so far it's just not an issue to
me.
This wasn't an issue for me either, until I was informed that I was wrong.
This is another item that I don't have time to waste contemplating theory
versus practice. I'll just let the Forms Designer generated code handle the
Dispose's on Forms controls and call it a day.
Also, at the end you mention "it only takes a moment to figure out if the
class actually implements a Dispose function..." which takes us full
circle
to the crux of the matter - some say that not everything that implements
a
Dispose needs to be Disposed. The question is which Components that
expose
a Dispose method need to have Dispose called on them?
I know what Component.Dispose does, and MarshallByRefComponent.Dispose,
etc. So
the only issue is whether the class itself implements a needed Dispose
override, and that only takes a second to check.
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. If I could get a solid definitive answer on this one
question, it would pretty much answer everything. It seems you have to
"know the secret 'Brotherhood of Le Architects' handshake" in order to get
this one particular piece of information.
And I do worry about that, but there's a flipside. I see a lot of code
that does a premature Dispose that only works because Dispose doesn't
really do anything. If some class I'm calling suddenly implement a
truly destructive dispose, my code might have a few temporary leaks but
that's better than simply crashing. And I do somewhat trust that decent
programmers will implement Finalize correctly.
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. 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.
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.
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.
> "It is up to the class user to call this method [Dispose]."
My original point, as desmonstrated by the Microsoft(tm)-sponsored
statement and code previously posted, is that the Finalize method can call
Dispose. The Finalize method is called via the GC. The GC normally is not
invoked by the "class user". It *can* happen; therefore the statement is
False.
Uh, well, if in your book can=false, then ok. In my book, if I build a
custom class that inherits from object and I create a Dispose method for it,
the GC isn't going to do squat as far as calling my Dispose method. So,
would I be wrong to reverse your logic and say that because it *might not*
get called, my statement is true? Sure!
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.
"Michael C#" <xy*@abcdef.com> wrote in message
news:oO***************@fe10.lga... 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.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl... Michael, 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.
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.
So basically, a beginning programmer can expect to put out potentially
problematic, sub-optimal code full of memory leaks until they learn [by
experience alone??] "which need to be disposed & which do not." That's
definitely a sub-optimal answer. As for learning the inner workings of classes in the .NET Framework, I
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".
I apologize if I misunderstood your statement that "However the System.Data
namespace I took the time to *learn* (rather then simple research) how the
DataSet object model actually works." As for the "intent", perhaps you
could explain further? I'm sure you don't mean by "intent" that the
"SqlConnection" class has the "intent" of allowing you to connect to a SQL
Server database. Or that the "Label" class has the "intent" of displaying
text. If this is the "intent", I'm sure MSDN Online is more than adequate
in detailing it. If "intent" is rather some arcane bit of trivia pertaining
to particular methods of a particular class...
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#" <xy*@abcdef.com> wrote in message
news:oO***************@fe10.lga... 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.
Your saying that the purpose of Dispose on components is for VS.NET's sake
and not for the running application's sake because VS.NET is causing the
component to hold on to unmanaged resources. What unmanaged resources does
a label or textbox hold on to that VS.NET must dispose of?
Your saying that Dispose is present because of the IDE and not the final
running application and that in that final running application, Dispose has
no use. That is what I take issue with, that is what is completely false.
Dispose does not exist as some sort of clean up tool for VS.NET.
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3u57j.vtv.df*****@woofix.local.dom... On 2005-03-22, Scott M. <s-***@nospam.nospam> wrote: You are confusing the VS.NET compiler and the CLR and you are making a
false
assumption about Dispose based on you mis-interpreted observation.
Your "exercise" only shows what VS.NET does during design-time, not what
the
CLR does at run-time
With all due respect, that makes absolutely no sense at all. As far as
the CLR is concerned, it *is* runtime. The CLR couldn't care less what
application is instantiating an object. VS.Net is just another
application in this case.
"Design-time" in this sense is simply an artifact of the Framework
libraries, it's the presence of a few properties in a few base classes.
As far as the CLR is concerned, your code is running, it's runtime.
and your explanation of why Dispose is there is flat
out wrong. Dispose is not there for the sake of the VS.NET design-time
interface.
Design-time is just that. While components do need to be instanced to
design them, this is a temporary design-time instance and is not
comparable
to what is going on at run-time.
What's the difference, and what do you think "temporary" means in that
sentence? Is there some kind of special "non-temporary" instantiation
that happens at other times?
It what possible way is it not comparable to runtime?
Your class has been instantiated. The GC will collect your class at
some point. Dispose will be called if you implement it. Various
properties and methods you define will be called. Your code is running,
and you may have aggregated unmanaged resources in your constructor
which means they need to be disposed. Face it, that's runtime.
You've connected two dots that may *seem*
like they are connectable, but in-fact, aren't.
You're long on flat statements, but very short on anything backing them
up.
What's your point exactly? Are you implying that VS.Net *doesn't* need
to call Dispose on custom controls and components instantiated in
designers? Why not?
On 2005-03-22, Michael C# <xy*@abcdef.com> wrote:
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3ubju.fa.df*****@woofix.local.dom... On 2005-03-22, Michael C# <xy*@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.Dispose does, and MarshallByRefComponent.Dispose,
etc. So
the only issue is whether the class itself implements a needed Dispose
override, and that only takes a second to check.
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.
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.
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.
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.).
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.
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.
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.
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.
On 2005-03-22, Scott M. <s-***@nospam.nospam> wrote: Your saying that the purpose of Dispose on components is for VS.NET's sake
and not for the running application's sake because VS.NET is causing the
component to hold on to unmanaged resources. What unmanaged resources does
a label or textbox hold on to that VS.NET must dispose of?
Quite often, a visual representation of itself which might consume GDI
resources. Database objects tend to hold onto a connection to the
database. More to the point, there's no way for VS.NET to know what
unmanaged resources the object is holding onto.
Your saying that Dispose is present because of the IDE and not the final
running application and that in that final running application, Dispose has
no use.
I'm saying that's true in some cases.
That is what I take issue with, that is what is completely false.
Well, gee, it's hard to argue with that impeccable logic. And you've
backed up your argument so well here with, well, pretty much nothing.
Dispose does not exist as some sort of clean up tool for VS.NET.
Dispose exists as, essentially, a clean up mechanism for consumers of a
class. VS.Net is one such consumer. VS.Net also has special needs at
design-time, that's exactly why there's a mechanism for classes to know
whether they're running under a design-time environment, so that they
can alter their behavior in that environment. Some objects need
different Dispose behavior depending on their environment.
This really isn't complex or controversial stuff. It's pretty basic.
doh,
Jay,
Forget it, this I have long ago checked with debugging, it is done by the
close. I became confused by this discussion.
Cor
Doh! are subject to change. What I intended on stating is that you need to
learn the "intent" or the workings of the class!
That should read "the "intent" or outer workings of the class
Jay
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl... Michael, 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.
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.
As for learning the inner workings of classes in the .NET Framework, I
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#" <xy*@yomomma.com> wrote in message
news:eE***************@TK2MSFTNGP15.phx.gbl... 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".
Michael, 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
In addition to the list of class members in MSDN Online & ILDASM or
Reflector that David mentions, you can use Object Browser in VS.NET.
Jay
"Michael C#" <xy*@abcdef.com> wrote in message
news:U8***************@fe10.lga...
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3ubju.fa.df*****@woofix.local.dom... On 2005-03-22, Michael C# <xy*@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?
In practice, it's really not an issue for me. I add it to components
and I know the components will be disposed for me. I realize there are
designs where this is a real issue, but so far it's just not an issue to
me.
This wasn't an issue for me either, until I was informed that I was wrong.
This is another item that I don't have time to waste contemplating theory
versus practice. I'll just let the Forms Designer generated code handle
the Dispose's on Forms controls and call it a day.
Also, at the end you mention "it only takes a moment to figure out if
the
class actually implements a Dispose function..." which takes us full
circle
to the crux of the matter - some say that not everything that implements
a
Dispose needs to be Disposed. The question is which Components that
expose
a Dispose method need to have Dispose called on them?
I know what Component.Dispose does, and MarshallByRefComponent.Dispose,
etc. So
the only issue is whether the class itself implements a needed Dispose
override, and that only takes a second to check.
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. If I could get a solid definitive answer on
this one question, it would pretty much answer everything. It seems you
have to "know the secret 'Brotherhood of Le Architects' handshake" in
order to get this one particular piece of information.
And I do worry about that, but there's a flipside. I see a lot of code
that does a premature Dispose that only works because Dispose doesn't
really do anything. If some class I'm calling suddenly implement a
truly destructive dispose, my code might have a few temporary leaks but
that's better than simply crashing. And I do somewhat trust that decent
programmers will implement Finalize correctly.
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.
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.
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.
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.
Cor,
That section of code is explained here: http://www.vbinfozine.com/a_disposable_comp.shtml
Hope this helps
Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Oj**************@tk2msftngp13.phx.gbl... Jay,
When you do that will you than as well implement this in your message.
This is in almost in every way in a class that implements Idisposable
\\\
'Form overrides dispose to clean up the component list.
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
If Not (components Is Nothing) Then
components.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
Private components As System.ComponentModel.IContainer
///
And therefore as well in every form, which means in my opinion that every
component will be disposed by a form close (However we can not reach that
in the standard situation without an explicit sub main, what than again
would mean that with a sub main that should be done for a form
explicitly).
That is for me a question which is still open, what is the logic behind
this.
Cor.
"Scott M." <s-***@nospam.nospam> wrote in message
news:Ov**************@TK2MSFTNGP10.phx.gbl... "It is up to the class user to call this method [Dispose]."
My original point, as desmonstrated by the Microsoft(tm)-sponsored
statement and code previously posted, is that the Finalize method can
call Dispose. The Finalize method is called via the GC. The GC normally
is not invoked by the "class user". It *can* happen; therefore the
statement is False.
Uh, well, if in your book can=false, then ok.
In my book the statement "It is up to the class user to call this method" =
false, as it is a documented fact that Dispose can be invoked by means other
than the "class user". Too easy Breezy.
In my book, if I build a custom class that inherits from object and I
create a Dispose method for it, the GC isn't going to do squat as far as
calling my Dispose method. So, would I be wrong to reverse your logic and
say that because it *might not* get called, my statement is true? Sure!
If you invoke Dispose in the Finalize method, as Microsoft has done in the
previously supplied sample code, then there is the possibility that it can
be invoked by GC. If you don't, then for that *one particular class*, it
cannot happen. However, based on the wild assumption that you're not the
only person in the Universe developing classes for the Framework (or just
maybe you are?) and that not everyone does things precisely the way you do
(some might even use Microsoft's own sample code as a starting point...
then again, this could be another wild and crazy out-of-bounds assumption),
it seems reasonable to conclude that there is at least one class out there
in the world in which the Finalize method invokes Dispose. That one,
single, lonely class which was not developed the "Scott M Way" makes your
gross generalization "false".
Thanks Jay.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... 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#" <xy*@abcdef.com> wrote in message
news:oO***************@fe10.lga... 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.
"Scott M." <s-***@nospam.nospam> wrote in message
news:er**************@tk2msftngp13.phx.gbl... 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.
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?
"Scott M." <s-***@nospam.nospam> wrote in message
news:er**************@tk2msftngp13.phx.gbl... 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.
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.
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" <df*****@woofix.local.dom> wrote in message
news:slrnd3ujab.rf.df*****@woofix.local.dom... On 2005-03-22, Michael C# <xy*@abcdef.com> wrote:
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3ubju.fa.df*****@woofix.local.dom... On 2005-03-22, Michael C# <xy*@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.Dispose does, and MarshallByRefComponent.Dispose,
etc. So
the only issue is whether the class itself implements a needed Dispose
override, and that only takes a second to check.
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.
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.
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.
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.).
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.
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.
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.
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.
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]" <Ja************@msn.com> wrote in message
news:OQ*************@TK2MSFTNGP14.phx.gbl... Doh!
are subject to change. What I intended on stating is that you need to
learn the "intent" or the workings of the class!
That should read "the "intent" or outer workings of the class
Jay
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl... Michael, 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.
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.
As for learning the inner workings of classes in the .NET Framework, I
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#" <xy*@yomomma.com> wrote in message
news:eE***************@TK2MSFTNGP15.phx.gbl... 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".
Michael, I'm not finding them overly useful in addressing my only simple question.
IMHO This thread has definitely shows that this is not a simple question!
:-)
I need to know exactly which classes need to be disposed and which do not.
That's all.
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.ShowDialog()
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.
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?
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#" <xy*@yomomma.com> wrote in message
news:uu*************@TK2MSFTNGP10.phx.gbl... "Scott M." <s-***@nospam.nospam> wrote in message
news:er**************@tk2msftngp13.phx.gbl... 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.
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.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... Consider objects that inherit from System.Windows.Forms.Form:
Dim dialog As New OptionsDialog ' inherits Form
dialog.ShowDialog()
dialog.Dispose()
Dim child As New MidChildForm ' inherits Form
child.Show()
See, now we're making progress. Two down. Now how many classes does that
leave? :)
Jay,
I was always curious about this and because of this thread I tested it. Dim dialog As New OptionsDialog ' inherits Form
dialog.ShowDialog()
dialog.Dispose()
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
Michael, See, now we're making progress. Two down.
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.ShowDialog()
dialog.Dispose()
dialog = New OptionsDialog
dialog.Show()
Its the exact same form, however based on how it is shown (Form.ShowDialog
or Form.Show) changes if Dispose is needed or not...
Now how many classes does that leave? :)
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#" <xy*@yomomma.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... Consider objects that inherit from System.Windows.Forms.Form:
Dim dialog As New OptionsDialog ' inherits Form
dialog.ShowDialog()
dialog.Dispose()
Dim child As New MidChildForm ' inherits Form
child.Show()
See, now we're making progress. Two down. Now how many classes does that
leave? :)
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
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" <no************@planet.nl> wrote in message
news:O2**************@TK2MSFTNGP15.phx.gbl... 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
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]" <Ja************@msn.com> wrote in message
news:OH**************@TK2MSFTNGP09.phx.gbl... Michael, See, now we're making progress. Two down.
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.ShowDialog()
dialog.Dispose()
dialog = New OptionsDialog
dialog.Show()
Its the exact same form, however based on how it is shown (Form.ShowDialog
or Form.Show) changes if Dispose is needed or not...
Now how many classes does that leave? :)
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#" <xy*@yomomma.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... Consider objects that inherit from System.Windows.Forms.Form:
Dim dialog As New OptionsDialog ' inherits Form
dialog.ShowDialog()
dialog.Dispose()
Dim child As New MidChildForm ' inherits Form
child.Show()
See, now we're making progress. Two down. Now how many classes does
that leave? :)
Cor, frm.showdialog
frm.close ' the same routine is called when the mainform is closing.
Yes same routine but for different reason, look at what the disposing
parameter is.
http://msdn.microsoft.com/library/de...poseTopic1.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/de...CloseTopic.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.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
Private Sub buttonClose_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles buttonClose.Click
Debug.WriteLine("Before close", "buttonClose_Click")
Me.Close()
Debug.WriteLine("After close", "buttonClose_Click")
End Sub
Public Shared Sub Main()
Dim dialog As New MainForm
dialog.ShowDialog()
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" <no************@planet.nl> wrote in message
news:OD**************@TK2MSFTNGP10.phx.gbl... Jay,
I was always curious about this and because of this thread I tested it.
Dim dialog As New OptionsDialog ' inherits Form
dialog.ShowDialog()
dialog.Dispose()
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]" <Ja************@msn.com> wrote in message
news:eC**************@TK2MSFTNGP15.phx.gbl... Cor, frm.showdialog
frm.close ' the same routine is called when the mainform is closing.
Yes same routine but for different reason, look at what the disposing
parameter is.
http://msdn.microsoft.com/library/de...poseTopic1.asp
Uh-oh. You mean to tell me that for this class, Finalize invoketh Dispose?
Jay,
Thanks, I will try it tomorrow here, I let you know my experience with it.
Cor
Michael,
Using the following in a VS.NET 2003 Windows Forms application I get:
Assemblies: 5
Types: 3384
Disposable: 226
Dispose: 132
There are significantly more then 5 assemblies in the entire .NET
Framework...
Const bindingAttr As BindingFlags = BindingFlags.DeclaredOnly _
Or BindingFlags.Instance Or BindingFlags.IgnoreCase _
Or BindingFlags.Public Or BindingFlags.NonPublic
Dim disposable As Type = GetType(IDisposable)
Dim countAssemblies As Integer
Dim countTypes As Integer
Dim countDisposable As Integer
Dim countDispose As Integer
For Each a As [Assembly] In AppDomain.CurrentDomain.GetAssemblies()
countAssemblies += 1
For Each t As Type In a.GetTypes()
countTypes += 1
If disposable.IsAssignableFrom(t) Then
Debug.WriteLine(t.FullName, "IDisposable")
countDisposable += 1
End If
Try
If t.GetMethod("Dispose", bindingAttr) Is Nothing Then
' No Dispose method.
Else
Debug.WriteLine(t.FullName, "Dispose")
countDispose += 1
End If
Catch ex As AmbiguousMatchException
Debug.WriteLine(t.FullName, "Dispose(s)")
countDispose += 1
End Try
Next
Next
Debug.WriteLine(countAssemblies, "Assemblies")
Debug.WriteLine(countTypes, "Types")
Debug.WriteLine(countDisposable, "Disposable")
Debug.WriteLine(countDispose, "Dispose")
NOTE: The "t.GetMethod" is an attempt to see if there is any Dispose method
declared on the type itself, as oppose to simply inheriting the method from
a base class...
Hope this helps
Jay
"Michael C#" <xy*@yomomma.com> wrote in message
news:Ou**************@TK2MSFTNGP12.phx.gbl... 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]" <Ja************@msn.com> wrote in message
news:OH**************@TK2MSFTNGP09.phx.gbl... Michael, See, now we're making progress. Two down.
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.ShowDialog()
dialog.Dispose()
dialog = New OptionsDialog
dialog.Show()
Its the exact same form, however based on how it is shown
(Form.ShowDialog or Form.Show) changes if Dispose is needed or not...
Now how many classes does that leave? :)
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#" <xy*@yomomma.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in
message news:%2****************@TK2MSFTNGP15.phx.gbl...
Consider objects that inherit from System.Windows.Forms.Form:
Dim dialog As New OptionsDialog ' inherits Form
dialog.ShowDialog()
dialog.Dispose()
Dim child As New MidChildForm ' inherits Form
child.Show()
See, now we're making progress. Two down. Now how many classes does
that leave? :)
Michael,
This class follows the Dispose/Finalize pattern.
Both Dispose() & Finalize() call Dispose(Boolean).
Hope this helps
Jay
"Michael C#" <xy*@yomomma.com> wrote in message
news:ej**************@TK2MSFTNGP15.phx.gbl...
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eC**************@TK2MSFTNGP15.phx.gbl... Cor, frm.showdialog
frm.close ' the same routine is called when the mainform is closing.
Yes same routine but for different reason, look at what the disposing
parameter is.
http://msdn.microsoft.com/library/de...poseTopic1.asp
Uh-oh. You mean to tell me that for this class, Finalize invoketh
Dispose?
> Your saying that Dispose is present because of the IDE and not the final running application and that in that final running application, Dispose
has
no use.
I'm saying that's true in some cases.
Well, actually you didn't say that the first time, you said:
Web controls are the perfect example of that. At design time, they need
to be disposed otherwise you'll squander windows resources. But at
runtime, there's nothing to dispose. Also, if you think about it,
there's no reasonable time for user code to dispose a web control at
runtime (Page.Unload maybe?).
What I got from this was you saying "you don't need to dispose web form
controls at run-time". And this is not true. As you say an OleDb
connection object at run-time will be holding on to unmanaged resources that
do not have anything to do with GDI and so this connection object should be
disposed at run-time.
That is what I take issue with, that is what is completely false.
Well, gee, it's hard to argue with that impeccable logic. And you've
backed up your argument so well here with, well, pretty much nothing.
And, gee, your sarcasm is something we can do without as well. Do you
disagree that OleDb connections hold unmanaged resources? What part of
saying that an OleDb connection needs to be disposed at run-time do you
disagree with?
Hey Michael, take a breath and relax for a moment.
I'm not trying to provoke you or cause an argument and I'd appreciate it if
you laid off the sarcasm as I haven't thrown any at you.
What I said (and you have blown completely out of proportion) was in
response to a question that was asked for a simple and clear definition of
what dispose is. What you've said is correct. I haven't and am not
disputing it, so it's not necessary for you to continue to hammer me with
the same text over and over.
Believe it or not, there may be folks out there who may create classes from
scratch (not explicitly inheriting from anything) and may not know anything
about the Finalize() method (I think this thread proves that). These are 2
pretty reasonable assumptions.
In this circumstance, it would be the class designer's job to create a
dispose and the class user's job to know to call it. My comments weren't
really referring to existing classes.
That's all I was saying. I never said "a class can't be created where its
dispose method is automatically called by a finalizer". And since not all
finalizers do call dispose, in fact, since not all classes even have a
finalizer, I think my statement about dispose is pretty accurate.
Sorry if this keeps you up at night.
"Michael C#" <xy*@yomomma.com> wrote in message
news:Os*************@TK2MSFTNGP15.phx.gbl...
"Scott M." <s-***@nospam.nospam> wrote in message
news:Ov**************@TK2MSFTNGP10.phx.gbl... "It is up to the class user to call this method [Dispose]."
My original point, as desmonstrated by the Microsoft(tm)-sponsored
statement and code previously posted, is that the Finalize method can
call Dispose. The Finalize method is called via the GC. The GC normally
is not invoked by the "class user". It *can* happen; therefore the
statement is False.
Uh, well, if in your book can=false, then ok.
In my book the statement "It is up to the class user to call this method"
= false, as it is a documented fact that Dispose can be invoked by means
other than the "class user". Too easy Breezy.
In my book, if I build a custom class that inherits from object and I
create a Dispose method for it, the GC isn't going to do squat as far as
calling my Dispose method. So, would I be wrong to reverse your logic
and say that because it *might not* get called, my statement is true?
Sure!
If you invoke Dispose in the Finalize method, as Microsoft has done in the
previously supplied sample code, then there is the possibility that it can
be invoked by GC. If you don't, then for that *one particular class*, it
cannot happen. However, based on the wild assumption that you're not the
only person in the Universe developing classes for the Framework (or just
maybe you are?) and that not everyone does things precisely the way you do
(some might even use Microsoft's own sample code as a starting point...
then again, this could be another wild and crazy out-of-bounds
assumption), it seems reasonable to conclude that there is at least one
class out there in the world in which the Finalize method invokes Dispose.
That one, single, lonely class which was not developed the "Scott M Way"
makes your gross generalization "false".
Cor, have you lost your mind?!
I am quoting YOU. YOU SAID: "There is no need to dispose any object of
system.data."
And then you have gone on to say that you didn't say it and now you are
saying I am all the time writing something else. What are you talking
about?!
Go back and read your own posts, would you?
"Cor Ligthert" <no************@planet.nl> wrote in message
news:uc**************@TK2MSFTNGP15.phx.gbl...
"Scott M." <s-***@nospam.nospam> schreef in bericht
"There is no need to dispose any object of system.data."
Scott why are you writing that, you are all the time writing something
else dit you change your mind?
To show you what misquoting is.
Cor
Well Michael, no offense to you, but I can do without your sarcasm and
seemingly personal attacks on me.
Your question makes perfect sense, and it is reasonable to think that a
simple, clear concise answer should be given. But, you know what Michael?
The answer isn't simple. To me, it seems that you want to blame me (or
someone) because the simple, clear, concise answer you seek doesn't exist in
that form.
I am not aware of any complete text that lists the do's and don'ts of what
to dispose or not. Instead, I am aware that circumstance by circumstance,
one can determine if a particular class should or shouldn't be disposed.
This is the best you are going to get, but you just won't accept that. And
when this answer is given, you just seem to scream a little louder at the
messenger about the message.
You know what? Some objects in the real world are dangerous if swallowed.
Can you please provide me with the complete list of those that are and those
that aren't?
"Michael C#" <xy*@yomomma.com> wrote in message
news:uu*************@TK2MSFTNGP10.phx.gbl... "Scott M." <s-***@nospam.nospam> wrote in message
news:er**************@tk2msftngp13.phx.gbl... 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.
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.
I think this is where a large part of the disconnect between the two of us
in this conversation is. I'm trying to get answers about the use of Dispose
on existing classes built into the .NET Framework, and you're talking about
user-created classes. I keep trying to explain that this I'm not concerned
with user-created classes, but rather with the existing .NET classes, but
somehow I keep getting responses that are at best peripherally related to
the existing .NET classes.
Lay off the sarcasm? Like this, eh? "> Sorry if this keeps you up at
night."
God knows I'll definitely sleep better now.
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl... Hey Michael, take a breath and relax for a moment.
I'm not trying to provoke you or cause an argument and I'd appreciate it
if you laid off the sarcasm as I haven't thrown any at you.
What I said (and you have blown completely out of proportion) was in
response to a question that was asked for a simple and clear definition of
what dispose is. What you've said is correct. I haven't and am not
disputing it, so it's not necessary for you to continue to hammer me with
the same text over and over.
Believe it or not, there may be folks out there who may create classes
from scratch (not explicitly inheriting from anything) and may not know
anything about the Finalize() method (I think this thread proves that).
These are 2 pretty reasonable assumptions.
In this circumstance, it would be the class designer's job to create a
dispose and the class user's job to know to call it. My comments weren't
really referring to existing classes.
That's all I was saying. I never said "a class can't be created where its
dispose method is automatically called by a finalizer". And since not all
finalizers do call dispose, in fact, since not all classes even have a
finalizer, I think my statement about dispose is pretty accurate.
Sorry if this keeps you up at night.
"Michael C#" <xy*@yomomma.com> wrote in message
news:Os*************@TK2MSFTNGP15.phx.gbl...
"Scott M." <s-***@nospam.nospam> wrote in message
news:Ov**************@TK2MSFTNGP10.phx.gbl... "It is up to the class user to call this method [Dispose]."
My original point, as desmonstrated by the Microsoft(tm)-sponsored
statement and code previously posted, is that the Finalize method can
call Dispose. The Finalize method is called via the GC. The GC
normally is not invoked by the "class user". It *can* happen;
therefore the statement is False.
Uh, well, if in your book can=false, then ok.
In my book the statement "It is up to the class user to call this method"
= false, as it is a documented fact that Dispose can be invoked by means
other than the "class user". Too easy Breezy.
In my book, if I build a custom class that inherits from object and I
create a Dispose method for it, the GC isn't going to do squat as far as
calling my Dispose method. So, would I be wrong to reverse your logic
and say that because it *might not* get called, my statement is true?
Sure!
If you invoke Dispose in the Finalize method, as Microsoft has done in
the previously supplied sample code, then there is the possibility that
it can be invoked by GC. If you don't, then for that *one particular
class*, it cannot happen. However, based on the wild assumption that
you're not the only person in the Universe developing classes for the
Framework (or just maybe you are?) and that not everyone does things
precisely the way you do (some might even use Microsoft's own sample code
as a starting point... then again, this could be another wild and crazy
out-of-bounds assumption), it seems reasonable to conclude that there is
at least one class out there in the world in which the Finalize method
invokes Dispose. That one, single, lonely class which was not developed
the "Scott M Way" makes your gross generalization "false".
OleDb Connections need to be disposed. 2 down, 83 to go!
"Scott M." <s-***@nospam.nospam> wrote in message
news:uL**************@tk2msftngp13.phx.gbl... Your saying that Dispose is present because of the IDE and not the final
running application and that in that final running application, Dispose
has
no use.
I'm saying that's true in some cases.
Well, actually you didn't say that the first time, you said:
Web controls are the perfect example of that. At design time, they need
to be disposed otherwise you'll squander windows resources. But at
runtime, there's nothing to dispose. Also, if you think about it,
there's no reasonable time for user code to dispose a web control at
runtime (Page.Unload maybe?).
What I got from this was you saying "you don't need to dispose web form
controls at run-time". And this is not true. As you say an OleDb
connection object at run-time will be holding on to unmanaged resources
that do not have anything to do with GDI and so this connection object
should be disposed at run-time.
That is what I take issue with, that is what is completely false.
Well, gee, it's hard to argue with that impeccable logic. And you've
backed up your argument so well here with, well, pretty much nothing.
And, gee, your sarcasm is something we can do without as well. Do you
disagree that OleDb connections hold unmanaged resources? What part of
saying that an OleDb connection needs to be disposed at run-time do you
disagree with?
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl... Well Michael, no offense to you, but I can do without your sarcasm and
seemingly personal attacks on me.
Nothing personal. But I could do without your generic answers directed at
me that relate to questions which I am not asking. As stated, I'm not
asking about user-created classes, yet I keep getting user-created class
hints, tips and answers. I'm not asking about broad generalities, but I
keep getting broad generalities.
Your question makes perfect sense, and it is reasonable to think that a
simple, clear concise answer should be given. But, you know what Michael?
The answer isn't simple. To me, it seems that you want to blame me (or
someone) because the simple, clear, concise answer you seek doesn't exist
in that form.
I am not aware of any complete text that lists the do's and don'ts of what
to dispose or not. Instead, I am aware that circumstance by circumstance,
one can determine if a particular class should or shouldn't be disposed.
This is the best you are going to get, but you just won't accept that.
And when this answer is given, you just seem to scream a little louder at
the messenger about the message.
The only problem I have with you, Scott, is that you keep answering the
wrong question. If you don't know the answer, I definitely won't hold it
against you, just say "I don't know the answer to the question you're
asking" and let someone else who might know take a shot at answering.
You know what? Some objects in the real world are dangerous if swallowed.
Can you please provide me with the complete list of those that are and
those that aren't?
So glad you asked!!! There are three "rules" in determining what to
swallow:
1) Never swallow anything
2) Swallow everything
3) Swallow only non-harmful things
Some people live by Rule #2, but I try to strive for Rule #3.
Hope that answered your question as well as you've answered mine!
Cor, please! READ MY POSTS before responding.
Did I say you used the word elaborate? No, I said you "seem to keep trying
to elaborate". Do you know what that means?
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ew**************@TK2MSFTNGP10.phx.gbl... Scott,
Sorry Cor, but I am quoting you. This is what you said. I responded to
it.
You seem to keep trying to elaborate and each time, you seem to
contradict yourself. At this point, I really don't know what you are
saying.
My thoughts on this are stated throughout the thread, but to sum up: I
agree that everything doesn't *need* to be disposed (labels), but data
objects most certainly do.
I never use the word elaborate where did I write that?
Cor.
> Lay off the sarcasm? Like this, eh? "> Sorry if this keeps you up at night."
God knows I'll definitely sleep better now.
That wasn't sarcasm. That was the only conclusion I could come up with why
you seem to be taking your frustrations out on me. This is what I call
sarcasm:
"However, based on the wild assumption that you're not the
only person in the Universe developing classes for the Framework (or just
maybe you are?) and that not everyone does things precisely the way you do
(some might even use Microsoft's own sample code as a starting point...
then again, this could be another wild and crazy out-of-bounds assumption),
it seems reasonable to conclude that there is at least one class out there
in the world in which the Finalize method invokes Dispose. That one,
single, lonely class which was not developed the "Scott M Way" makes your
gross generalization "false". "
> Nothing personal. But I could do without your generic answers directed at me that relate to questions which I am not asking. As stated, I'm not
asking about user-created classes, yet I keep getting user-created class
hints, tips and answers. I'm not asking about broad generalities, but I
keep getting broad generalities.
You have every right to not respond to information you deem not related to
you. You do not have the right to be sarcastic and borderline mean to
people posting information in a public place with the best of intentions for
all to consume.
The only problem I have with you, Scott, is that you keep answering the
wrong question. If you don't know the answer, I definitely won't hold it
against you, just say "I don't know the answer to the question you're
asking" and let someone else who might know take a shot at answering.
Again, I gave you the answer (below), you just don't want to accept it.
[I am not aware of any complete text that lists the do's and don'ts of what
to dispose or not. Instead, I am aware that circumstance by circumstance,
one can determine if a particular class should or shouldn't be disposed.] You know what? Some objects in the real world are dangerous if
swallowed. Can you please provide me with the complete list of those that
are and those that aren't?
So glad you asked!!! There are three "rules" in determining what to
swallow:
1) Never swallow anything
2) Swallow everything
3) Swallow only non-harmful things
Some people live by Rule #2, but I try to strive for Rule #3.
Hope that answered your question as well as you've answered mine!
Ah but see, you didn't answer the question that "I was asking". See, I
didn't ask what you or other people eat, I asked for a complete list of what
is and isn't harmful to eat. So as soon as you get that list to me, I'll
get you the imaginary list you are looking for.
"Scott M." <s-***@nospam.nospam> wrote in message
news:uo*************@TK2MSFTNGP12.phx.gbl... Again, I gave you the answer (below), you just don't want to accept it.
[I am not aware of any complete text that lists the do's and don'ts of
what
to dispose or not. Instead, I am aware that circumstance by circumstance,
one can determine if a particular class should or shouldn't be disposed.]
Of course I can readily accept the fact that you do not know this
information; however, you must accept the fact that someone else may know,
or at least be aware of good resources for finding, this specific
information. You know what? Some objects in the real world are dangerous if
swallowed. Can you please provide me with the complete list of those
that are and those that aren't?
So glad you asked!!! There are three "rules" in determining what to
swallow:
1) Never swallow anything
2) Swallow everything
3) Swallow only non-harmful things
Ah but see, you didn't answer the question that "I was asking". See, I
didn't ask what you or other people eat, I asked for a complete list of
what is and isn't harmful to eat. So as soon as you get that list to me,
I'll get you the imaginary list you are looking for.
Ah, now perhaps you understand my frustration with your "answers" to my
question. Perhaps not.
Like you, I didn't ask what you or other people Dispose, I asked for a
complete list of what should and should not be Disposed. Which should make
a much, much shorter list than items that can be swallowed. After all,
there are far more things that can be "swallowed" than there are built-in
classes in the .NET Framework that expose a Dispose method; however, as you
can see, your answers apply to this situation (and probably any other
situation you could possibly think up), without losing any of their
practical value.
Now, if you want to get into more practical detail, we could look at all
objects that expose a "Swallow" method. We can further refine the "list" to
"you will learn what not to swallow by experience" (you will learn when to
use Dispose by experience), "you can teach yourself advanced Chemistry and
Biology courses and perform chemical analysis on everything that has a
Swallow method" (after all you can learn IL and use ILDASM and Object
Browser to determine which objects to Dispose), you can follow the
Manufacturer's Recommendations for Swallowing - assuming there are any, and
make note of the exceptions. I can also tell you that it is correct to
swallow chocolate milk and chicken casserole based on their Swallow
interfaces. That's 2 down, how many to go?
Now *that* is an excellent tool to discover a baseline. Thank you.
IMHO, MS just needs to dedicate a person or two to documenting this and
letting people know when and how to use their product; rather than leaving
it to people to accidentally discover, or spend hours researching this when
they could be doing far more productive things. It would seem the next step
would be to determine if the Dispose and Disposable types use unmanaged
resources. Do you think there is a programmatic way to determine this?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eZ**************@tk2msftngp13.phx.gbl... Michael,
Using the following in a VS.NET 2003 Windows Forms application I get:
Assemblies: 5
Types: 3384
Disposable: 226
Dispose: 132
There are significantly more then 5 assemblies in the entire .NET
Framework...
Const bindingAttr As BindingFlags = BindingFlags.DeclaredOnly _
Or BindingFlags.Instance Or BindingFlags.IgnoreCase _
Or BindingFlags.Public Or BindingFlags.NonPublic
Dim disposable As Type = GetType(IDisposable)
Dim countAssemblies As Integer
Dim countTypes As Integer
Dim countDisposable As Integer
Dim countDispose As Integer
For Each a As [Assembly] In AppDomain.CurrentDomain.GetAssemblies()
countAssemblies += 1
For Each t As Type In a.GetTypes()
countTypes += 1
If disposable.IsAssignableFrom(t) Then
Debug.WriteLine(t.FullName, "IDisposable")
countDisposable += 1
End If
Try
If t.GetMethod("Dispose", bindingAttr) Is Nothing Then
' No Dispose method.
Else
Debug.WriteLine(t.FullName, "Dispose")
countDispose += 1
End If
Catch ex As AmbiguousMatchException
Debug.WriteLine(t.FullName, "Dispose(s)")
countDispose += 1
End Try
Next
Next
Debug.WriteLine(countAssemblies, "Assemblies")
Debug.WriteLine(countTypes, "Types")
Debug.WriteLine(countDisposable, "Disposable")
Debug.WriteLine(countDispose, "Dispose")
NOTE: The "t.GetMethod" is an attempt to see if there is any Dispose
method declared on the type itself, as oppose to simply inheriting the
method from a base class...
Hope this helps
Jay
"Michael C#" <xy*@yomomma.com> wrote in message
news:Ou**************@TK2MSFTNGP12.phx.gbl... 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]" <Ja************@msn.com> wrote in message
news:OH**************@TK2MSFTNGP09.phx.gbl... Michael,
See, now we're making progress. Two down.
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.ShowDialog()
dialog.Dispose()
dialog = New OptionsDialog
dialog.Show()
Its the exact same form, however based on how it is shown
(Form.ShowDialog or Form.Show) changes if Dispose is needed or not...
Now how many classes does that leave? :)
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#" <xy*@yomomma.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in
message news:%2****************@TK2MSFTNGP15.phx.gbl...
> Consider objects that inherit from System.Windows.Forms.Form:
>
> Dim dialog As New OptionsDialog ' inherits Form
> dialog.ShowDialog()
> dialog.Dispose()
>
> Dim child As New MidChildForm ' inherits Form
> child.Show()
See, now we're making progress. Two down. Now how many classes does
that leave? :)
This thread has been closed and replies have been disabled. Please start a new discussion. |
