P
pvdg42
active said:
Unless you have resource issues with your application, you should simply
allow automatic garbage collection to do its job.
In most cases, you do not need to interfere.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Unless you have resource issues with your application, you should simply
allow automatic garbage collection to do its job.
In most cases, you do not need to interfere.
A
active
In the main program I check to see if a certain form has been disposed.
Does it make sense in that form's FormClosed event to do:
Me.Dispose to make sure it is disposed the next time I check.
Or is that automatic?
Thanks
Does it make sense in that form's FormClosed event to do:
Me.Dispose to make sure it is disposed the next time I check.
Or is that automatic?
Thanks
M
Michael C
pvdg42 said:Unless you have resource issues with your application, you should simply
allow automatic garbage collection to do its job.
In most cases, you do not need to interfere.
Aren't you meant to call Dispose on anything that has a dispose method?
Michael
C
Cor Ligthert [MVP]
Active,
It seems strange, but AFAIK are the forms which are used with
Form.Showdialog using the dialogresources. Those showdialogforms are one of
the exceptions to dispose, because they are not involved in the automatic
disposing of the mainform.
Cor
It seems strange, but AFAIK are the forms which are used with
Form.Showdialog using the dialogresources. Those showdialogforms are one of
the exceptions to dispose, because they are not involved in the automatic
disposing of the mainform.
Cor
R
RobinS
Michael C said:Aren't you meant to call Dispose on anything that has a dispose method?
Michael
No, only unmanaged resources like COM stuff. When an object goes out of
scope, it will be marked for garbage collection whether you dispose of it
or not.
Robin S.
R
RobinS
I agree; I have heard that one should dispose of any forms that you do a
ShowDialog() on.
Robin S.
ShowDialog() on.
Robin S.
M
Michael C
RobinS said:No, only unmanaged resources like COM stuff. When an object goes out of
scope, it will be marked for garbage collection whether you dispose of it
or not.
That is true of course, even for COM objects I believe (the garbage
collector will call dispose on them, hence calling Release). But anything
with a Dispose method indicates that it is using some finite resource that
should be disposed of asap. Eg, Pens, Brushes etc are finite and need to be
disposed. Same with database objects like connections and datareaders. Forms
are no different to this in that they are a finite object. The only
difference is that generally forms are not created and closed at a great
rate so usually it doesn't matter if they are not disposed of immediately.
Certainly there will be a large number of apps that never dispose of a form
object and run fine and will do so for a long time. BUT technically you
should call dispose. I did some tests on this once and found that the form
handle still exists until the form is disposed. Other resources on the form
such as bitmaps will be left in memory also. Because of this I generally
dispose of forms when I can but don't consider it critical.
Michael
A
active
I can't wait for the GC because I may check to see if it is disposed before
it runs.
I shouldn't have included "Or is that automatic?" as that confused what I
needed to know.
Since no one said "do not call dispose from inside the form" I'm doing that.
It's not clear to me what happens after a form disposes itself. How can it
finish the FormClosed event?
Thanks to all for the help
it runs.
I shouldn't have included "Or is that automatic?" as that confused what I
needed to know.
Since no one said "do not call dispose from inside the form" I'm doing that.
It's not clear to me what happens after a form disposes itself. How can it
finish the FormClosed event?
Thanks to all for the help
R
rowe_newsgroups
That is true of course, even for COM objects I believe (the garbage
collector will call dispose on them, hence calling Release). But anything
with a Dispose method indicates that it is using some finite resource that
should be disposed of asap. Eg, Pens, Brushes etc are finite and need to be
disposed. Same with database objects like connections and datareaders. Forms
are no different to this in that they are a finite object. The only
difference is that generally forms are not created and closed at a great
rate so usually it doesn't matter if they are not disposed of immediately.
Certainly there will be a large number of apps that never dispose of a form
object and run fine and will do so for a long time. BUT technically you
should call dispose. I did some tests on this once and found that the form
handle still exists until the form is disposed. Other resources on the form
such as bitmaps will be left in memory also. Because of this I generally
dispose of forms when I can but don't consider it critical.
Michael
It seems we could adapt Pascal's gamble to this situation:
What harm can be caused by calling Dispose on any method that
implements IDisposable?
AFAIK none (outside of having to type .Dispose() or a using block)
What harm can be caused by NOT calling Dispose on any method that
implements IDisposable?
Usually none, but in some cases it can lead to memory leaks.
I'm not an expert on disposing and memory usage / garbage collection
in .Net so please correct me if I'm wrong with the above statements.
It just seems to me that manually disposing of objects should fall
into the "better safe than sorry" category?
Thanks,
Seth Rowe
A
active
I learned more.
The doc for FormClosing (not for FormClosed) says the form get disposed
when the form is Closed, so I guess any call would be redundant.
The doc for FormClosing (not for FormClosed) says the form get disposed
when the form is Closed, so I guess any call would be redundant.
C
Cor Ligthert [MVP]
Rowe,
Just because of the fact that 20% of the classes implements IDisposable.
(And it are probably the most used)
It is just available, the same as on every control is the Text property and
on even every object the toString method. As well is on every object the
Hashtable. Does that mean in your opinion that you always should use
ToString when using an integer or a double?
Every action takes time. .Net is build to save those time by using managing
code. Managing the finalizing for you.
Cor
Just because of the fact that 20% of the classes implements IDisposable.
(And it are probably the most used)
It is just available, the same as on every control is the Text property and
on even every object the toString method. As well is on every object the
Hashtable. Does that mean in your opinion that you always should use
ToString when using an integer or a double?
Every action takes time. .Net is build to save those time by using managing
code. Managing the finalizing for you.
Cor
R
rowe_newsgroups
Cor,
I'm not sure I know what you're trying to say here?
These examples you gave have nothing to do with what I was saying
about Dispose. My comments have nothing to do with calling dispose
just because it's there - it has to do calling it because it's purpose
is to clean up resources.
Do you mean typing time or execution time here? If typing time then
I'd say your getting lazy, if execution time I'd wonder how you came
to the conclusion that use Dispose to release resources decreases
performance.
If I'm not mistaking, the garbage collector will call the Finalize
method for you, and Finalize usually calls Dispose, and the garbage
collector is only called when it needs to be called (versus being
called whenever an object goes out of scope) right?
i.e.
' typed in message
private sub Foo()
Dim someObject as IDisposable = new IDisposableObject()
' use someObject
end sub
The someObject has been instantiated and immediately goes out of
scope, marking it for garbage collection. Some time later (maybe
milliseconds maybe minutes maybe longer) the garbage collector is
called. The garbage collector calls someObject's finalize method which
in turn (might) call the Dispose method. If this is true, someObject
will be disposed of only when garbage collected - which might take a
while. The time the object spends in "limbo" between going out of
scope and being finalized and disposed it is just wasting resources.
So by not calling Dispose manually it will take more time before the
object's resources are released right? So why not change the sub to
this?
' typed in message
private sub Foo()
Dim someObject as IDisposable = new IDisposableObject()
' use someObject
someObject.Dispose()
end sub
or this:
' typed in message
private sub Foo()
Dim someObject as IDisposable = new IDisposableObject()
Using (someObject)
' use someObject
End Using
end sub
This way at least I know that when the code returns from Dispose that
resources have been cleaned up and I no longer have to wait on the GC
to collect. Also, wouldn't this cause the GC to be use less often
(thus increasing performance) as the GC would need to be called less
often?
Thanks,
Seth Rowe
Just because of the fact that 20% of the classes implements IDisposable.
(And it are probably the most used)
I'm not sure I know what you're trying to say here?
It is just available, the same as on every control is the Text property and
on even every object the toString method. As well is on every object the
Hashtable. Does that mean in your opinion that you always should use
ToString when using an integer or a double?
These examples you gave have nothing to do with what I was saying
about Dispose. My comments have nothing to do with calling dispose
just because it's there - it has to do calling it because it's purpose
is to clean up resources.
Every action takes time.
Do you mean typing time or execution time here? If typing time then
I'd say your getting lazy, if execution time I'd wonder how you came
to the conclusion that use Dispose to release resources decreases
performance.
Managing the finalizing for you.
If I'm not mistaking, the garbage collector will call the Finalize
method for you, and Finalize usually calls Dispose, and the garbage
collector is only called when it needs to be called (versus being
called whenever an object goes out of scope) right?
i.e.
' typed in message
private sub Foo()
Dim someObject as IDisposable = new IDisposableObject()
' use someObject
end sub
The someObject has been instantiated and immediately goes out of
scope, marking it for garbage collection. Some time later (maybe
milliseconds maybe minutes maybe longer) the garbage collector is
called. The garbage collector calls someObject's finalize method which
in turn (might) call the Dispose method. If this is true, someObject
will be disposed of only when garbage collected - which might take a
while. The time the object spends in "limbo" between going out of
scope and being finalized and disposed it is just wasting resources.
So by not calling Dispose manually it will take more time before the
object's resources are released right? So why not change the sub to
this?
' typed in message
private sub Foo()
Dim someObject as IDisposable = new IDisposableObject()
' use someObject
someObject.Dispose()
end sub
or this:
' typed in message
private sub Foo()
Dim someObject as IDisposable = new IDisposableObject()
Using (someObject)
' use someObject
End Using
end sub
This way at least I know that when the code returns from Dispose that
resources have been cleaned up and I no longer have to wait on the GC
to collect. Also, wouldn't this cause the GC to be use less often
(thus increasing performance) as the GC would need to be called less
often?
Thanks,
Seth Rowe
C
Chris Dunaway
I learned more.
The doc for FormClosing (not for FormClosed) says the form get disposed
when the form is Closed, so I guess any call would be redundant.
That is true if the form was shown using the Show method.
When a form is shown using the Show method, it is automatically
disposed when it is closed. But if the form is shown using ShowDialog
as Cor alluded to earlier, then you must call Dispose on it yourself.
Chris
M
Michael C
Cor Ligthert said:Rowe,
Just because of the fact that 20% of the classes implements IDisposable.
(And it are probably the most used)
So 20% of classes are built on top of finite resources.
It is just available, the same as on every control is the Text property
and on even every object the toString method. As well is on every object
the Hashtable. Does that mean in your opinion that you always should use
ToString when using an integer or a double?
What?
Every action takes time. .Net is build to save those time by using
managing code. Managing the finalizing for you.
Disposing has to be done at some time, you're only deferring it.
Michael
M
Michael C
rowe_newsgroups said:It seems we could adapt Pascal's gamble to this situation:
What harm can be caused by calling Dispose on any method that
implements IDisposable?
AFAIK none (outside of having to type .Dispose() or a using block)
The downside is that you might accidentally cause a bug when you dispose an
object in use, but this is just good testing.
What harm can be caused by NOT calling Dispose on any method that
implements IDisposable?
Usually none, but in some cases it can lead to memory leaks.
When you do get bugs from not calling dispose these bugs are often random,
very difficult to reproduce, very difficult to track down and very difficult
to know for sure they are gone.
I'm not an expert on disposing and memory usage / garbage collection
in .Net so please correct me if I'm wrong with the above statements.
My understanding is that if it's got a dispose method you should call it.
It just seems to me that manually disposing of objects should fall
into the "better safe than sorry" category?
I think it is more than that, it is considered required by MS.
Michael
R
rowe_newsgroups
The downside is that you might accidentally cause a bug when you dispose an
object in use, but this is just good testing.
When you do get bugs from not calling dispose these bugs are often random,
very difficult to reproduce, very difficult to track down and very difficult
to know for sure they are gone.
My understanding is that if it's got a dispose method you should call it.
I think it is more than that, it is considered required by MS.
Michael
Thanks for the confirmations Michael.
Thanks,
Seth Rowe
A
active
Thanks for making sure I noticed that
Chris Dunaway said:That is true if the form was shown using the Show method.
When a form is shown using the Show method, it is automatically
disposed when it is closed. But if the form is shown using ShowDialog
as Cor alluded to earlier, then you must call Dispose on it yourself.
Chris
M
Michael C
Chris Dunaway said:That is true if the form was shown using the Show method.
When a form is shown using the Show method, it is automatically
disposed when it is closed. But if the form is shown using ShowDialog
as Cor alluded to earlier, then you must call Dispose on it yourself.
My belief was you needed to dispose all forms after they were closed. You
say only if it's shown using ShowDialog. But I've just tested and my tests
indicate we are both wrong. For a form shown via either method the window
handle for the form gets destroyed immediately it is closed. I tested using
the close button on the title bar, using a cancel button and just calling
Me.Close. In all cases the window itself was destroyed immediately. I
checked this by overriding WndProc and looking for WM_DESTROY and confirmed
it using spy++. I could not get the window itself to remain after the form
was closed.
Michael
C
Cor Ligthert [MVP]
But anything with a Dispose method indicates that it is using some finite
No, it shows only that it implements IDisposable, probably in a very high
derived level.
The component class does that and therefore Dispose is by instance in every
Control.
As it is once calculated by Jon Skeet that alone is in 20% of the classes.
In 100% of the classes is the ToString methode. This does not mean that it
should be used asap.
Cor
resource that
should be disposed of asap.
No, it shows only that it implements IDisposable, probably in a very high
derived level.
The component class does that and therefore Dispose is by instance in every
Control.
As it is once calculated by Jon Skeet that alone is in 20% of the classes.
In 100% of the classes is the ToString methode. This does not mean that it
should be used asap.
Cor
M
Michael C
Cor Ligthert said:No, it shows only that it implements IDisposable, probably in a very high
derived level.
The component class does that and therefore Dispose is by instance in
every Control.
As it is once calculated by Jon Skeet that alone is in 20% of the classes.
Still, Dispose should be called on forms. In this case it is not necessary
because Dispose is called for you. It is a bit of a special situation
because in most cases it is not. Can you name any class in dot net that has
dispose where it makes no sense at all to have it? Something might exist but
it will be rare.
In 100% of the classes is the ToString methode. This does not mean that it
should be used asap.
The MS documentation specifies that IDispose indicates a resourse that needs
disposing asap. The ToString documention doesn't specify any such
requirement.
Michael