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

" active" <activeNOSPAM@a-znet.comwrote in message
news:uGbgpnRZHHA.208@TK2MSFTNGP05.phx.gbl...

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
>

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.

"pvdg42" <pvdg42@newsgroups.nospamwrote in message
news:OoTfLCSZHHA.2432@TK2MSFTNGP03.phx.gbl...

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

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


" active" <activeNOSPAM@a-znet.comschreef in bericht
news:uGbgpnRZHHA.208@TK2MSFTNGP05.phx.gbl...

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
>

"Michael C" <nospam@nospam.comwrote in message
news:ub7rYcSZHHA.1260@TK2MSFTNGP03.phx.gbl...

"pvdg42" <pvdg42@newsgroups.nospamwrote in message
news:OoTfLCSZHHA.2432@TK2MSFTNGP03.phx.gbl...

>
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.

I agree; I have heard that one should dispose of any forms that you do a
ShowDialog() on.

Robin S.
------------------------------------
"Cor Ligthert [MVP]" <notmyfirstname@planet.nlwrote in message
news:O1KRHBTZHHA.1008@TK2MSFTNGP03.phx.gbl...

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
>
>
" active" <activeNOSPAM@a-znet.comschreef in bericht
news:uGbgpnRZHHA.208@TK2MSFTNGP05.phx.gbl...

>
>

"RobinS" <RobinS@NoSpam.yah.nonewrote in message
news:ofydnSsgNujr2GvYnZ2dnUVZ_qunnZ2d@comcast.com. ..

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

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

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
>

On Mar 13, 2:56 am, "Michael C" <nos...@nospam.comwrote:

"RobinS" <Rob...@NoSpam.yah.nonewrote in message
>
news:ofydnSsgNujr2GvYnZ2dnUVZ_qunnZ2d@comcast.com. ..
>

>
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

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.

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


"rowe_newsgroups" <rowe_email@yahoo.comschreef in bericht
news:1173790956.876214.81580@v33g2000cwv.googlegro ups.com...

On Mar 13, 2:56 am, "Michael C" <nos...@nospam.comwrote:

>
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
>

Cor,

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


On Mar 13, 2:33 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

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
>
"rowe_newsgroups" <rowe_em...@yahoo.comschreef in berichtnews:1173790956.876214.81580@v33g2000cwv.go oglegroups.com...
>

>

>

>

>

>

>

>

>

>

>

>

On Mar 13, 9:30 am, " active" <activeNOS...@a-znet.comwrote:

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

"Cor Ligthert [MVP]" <notmyfirstname@planet.nlwrote in message
news:%23r2492ZZHHA.4368@TK2MSFTNGP06.phx.gbl...

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

"rowe_newsgroups" <rowe_email@yahoo.comwrote in message

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

Thanks for making sure I noticed that

"Chris Dunaway" <dunawayc@gmail.comwrote in message
news:1173817553.298094.315890@b75g2000hsg.googlegr oups.com...

On Mar 13, 9:30 am, " active" <activeNOS...@a-znet.comwrote:

>
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
>

On Mar 13, 6:59 pm, "Michael C" <nos...@nospam.comwrote:

"rowe_newsgroups" <rowe_em...@yahoo.comwrote in message

>

>
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

"Chris Dunaway" <dunawayc@gmail.comwrote in message
news:1173817553.298094.315890@b75g2000hsg.googlegr oups.com...

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

>But anything with a Dispose method indicates that it is using some finite

>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


"rowe_newsgroups" <rowe_email@yahoo.comschreef in bericht
news:1173813969.493193.58710@c51g2000cwc.googlegro ups.com...

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
>
>
On Mar 13, 2:33 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

>
>

"Cor Ligthert [MVP]" <notmyfirstname@planet.nlwrote in message
news:e%237tyxfZHHA.3272@TK2MSFTNGP03.phx.gbl...

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

I can call thousands but just one

Label?

Cor

"Michael C" <nospam@nospam.comschreef in bericht
news:%231YysFgZHHA.1400@TK2MSFTNGP06.phx.gbl...

"Cor Ligthert [MVP]" <notmyfirstname@planet.nlwrote in message
news:e%237tyxfZHHA.3272@TK2MSFTNGP03.phx.gbl...

>
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.
>

>
The MS documentation specifies that IDispose indicates a resourse that
needs disposing asap. The ToString documention doesn't specify any such
requirement.
>
Michael
>

Label?

Do you have the inner implementation details of a Label? How can you
call something a waste of time if you can't be sure that it does
absolutely nothing?

Anyways, at the very least wouldn't calling dispose at least prevent
the Label from having to go through two cycles of garbage collection?
(as it probably uses GC.SuppressFinalize)

Besides if it wasn't needed, why would the parent call it's dispose
method from it's own dispose method?

Lastly, let me adapt Michael's question a little:

Can you show us some examples where manually calling Dispose is
detrimental to the application?

Thanks,

Seth Rowe


On Mar 14, 7:36 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

I can call thousands but just one
>
Label?
>
Cor
>
"Michael C" <nos...@nospam.comschreef in berichtnews:%231YysFgZHHA.1400@TK2MSFTNGP06.phx.gb l...
>

>

>

>

>

"Michael C" <nospam@nospam.comwrote in message
news:uh8$gMdZHHA.4420@TK2MSFTNGP02.phx.gbl...

"Chris Dunaway" <dunawayc@gmail.comwrote in message
news:1173817553.298094.315890@b75g2000hsg.googlegr oups.com...

>
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
>

I'm not sure if this is relevant, but you can continue to access (I think)
the (ShowDialog) window's properties after it is closed. Doesn't that mean
it is not disposed?

On Mar 13, 8:00 pm, "Michael C" <nos...@nospam.comwrote:

"Chris Dunaway" <dunaw...@gmail.comwrote in message
>
news:1173817553.298094.315890@b75g2000hsg.googlegr oups.com...
>

>

>
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.

I'm not sure that the fact that the window handle gets destroyed is
proof that the form object has been disposed.

>From the docs:

"When a form is closed, all resources created within the object are
closed and the form is disposed. The two conditions when a form is not
disposed on Close is when (1) it is part of a multiple-document
interface (MDI) application, and the form is not visible; and (2) you
have displayed the form using ShowDialog. In these cases, you will
need to call Dispose manually to mark all of the form's controls for
garbage collection."

Further, if you try these two snippets of code:

Dim frm As New Form2
frm.ShowDialog()
System.Threading.Thread.Sleep(3000)
frm.ShowDialog()
frm.Dispose()

Dim frm2 As New Form2
frm2.Show()
System.Threading.Thread.Sleep(3000)
frm.Show()

The first will work correctly, even after closing the form. The
second will throw an exception.

One reason for not disposing a form when shown using ShowDialog is
that you may wish to access the form's properties after it has been
closed. The Open File Dialog is a good example of this.

But if you try to access a form that was displayed with Show() after
it has been closed, you will get an exception.

Chris

I'm not sure that the fact that the window handle gets destroyed is

proof that the form object has been disposed.

You are absolutely right - the destruction of the window handle has
nothing to do with the disposing of the form.

Here's a quick demo:

Create a new windows app and drop 3 buttons onto the form, then add
this code to the form:

Public Class Form1

<System.Runtime.InteropServices.DllImport("user32. dll")_
Public Shared Function DestroyWindow(ByVal hWnd As IntPtr) As
Boolean

End Function

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
DestroyWindow(Me.Handle)
End Sub

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button2.Click
Dim f As New Form1()
f.Text = "Created With Show"
f.Show()
End Sub

Private Sub Button3_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button3.Click
Dim f2 As New Form1()
f2.Text = "Created With ShowDialog"
f2.ShowDialog()
End Sub

'Form overrides dispose to clean up the component list.
<System.Diagnostics.DebuggerNonUserCode()_
Protected Overrides Sub Dispose(ByVal disposing As Boolean)
Try
MsgBox(String.Format("Form {0} is disposing", Me.Text))
If disposing AndAlso components IsNot Nothing Then
components.Dispose()
End If
Finally
MyBase.Dispose(disposing)
End Try
End Sub

End Class

Press Button2 or Button3 to create and Show/ShowDialog a new Form1
form. Then on the newly created form press it's Button1 to invoke the
DestroyWindow api call on the form. *Poof* goes the form, but no
Dispose messagebox will be shown. Only when the startup form closes
(and the application exits) will the Dispose be called on these forms
and the messages show up.

Thanks,

Seth Rowe


On Mar 14, 9:50 am, "Chris Dunaway" <dunaw...@gmail.comwrote:

On Mar 13, 8:00 pm, "Michael C" <nos...@nospam.comwrote:
>
>
>

>

>

>

>

>
I'm not sure that the fact that the window handle gets destroyed is
proof that the form object has been disposed.
>

>
"When a form is closed, all resources created within the object are
closed and the form is disposed. The two conditions when a form is not
disposed on Close is when (1) it is part of a multiple-document
interface (MDI) application, and the form is not visible; and (2) you
have displayed the form using ShowDialog. In these cases, you will
need to call Dispose manually to mark all of the form's controls for
garbage collection."
>
Further, if you try these two snippets of code:
>
Dim frm As New Form2
frm.ShowDialog()
System.Threading.Thread.Sleep(3000)
frm.ShowDialog()
frm.Dispose()
>
Dim frm2 As New Form2
frm2.Show()
System.Threading.Thread.Sleep(3000)
frm.Show()
>
The first will work correctly, even after closing the form. The
second will throw an exception.
>
One reason for not disposing a form when shown using ShowDialog is
that you may wish to access the form's properties after it has been
closed. The Open File Dialog is a good example of this.
>
But if you try to access a form that was displayed with Show() after
it has been closed, you will get an exception.
>
Chris

No do you?

Cor

"rowe_newsgroups" <rowe_email@yahoo.comschreef in bericht
news:1173876085.239044.300460@l77g2000hsb.googlegr oups.com...

>
Do you have the inner implementation details of a Label? How can you
call something a waste of time if you can't be sure that it does
absolutely nothing?
>
Anyways, at the very least wouldn't calling dispose at least prevent
the Label from having to go through two cycles of garbage collection?
(as it probably uses GC.SuppressFinalize)
>
Besides if it wasn't needed, why would the parent call it's dispose
method from it's own dispose method?
>
Lastly, let me adapt Michael's question a little:
>
Can you show us some examples where manually calling Dispose is
detrimental to the application?
>
Thanks,
>
Seth Rowe
>
>
On Mar 14, 7:36 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

>
>

Yes,

And to make this ever more relevant, why did they make the method IsDisposed
for.

Although we are here again seeing people who are completely mixing up
Finalizing with Disposing.

Cor

" active" <activeNOSPAM@a-znet.comschreef in bericht
news:%23CFbsmjZHHA.3272@TK2MSFTNGP03.phx.gbl...

>
"Michael C" <nospam@nospam.comwrote in message
news:uh8$gMdZHHA.4420@TK2MSFTNGP02.phx.gbl...

I'm not sure if this is relevant, but you can continue to access (I think)
the (ShowDialog) window's properties after it is closed. Doesn't that mean
it is not disposed?
>
>