Does it make sense in FormClosed to do Me.Dispose

" active" <ac**********@a-znet.comwrote in message
news:uG*************@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" <pv****@newsgroups.nospamwrote in message
news:Oo**************@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" <ac**********@a-znet.comschreef in bericht
news:uG*************@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" <no****@nospam.comwrote in message
news:ub**************@TK2MSFTNGP03.phx.gbl...

"pvdg42" <pv****@newsgroups.nospamwrote in message
news:Oo**************@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

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]" <no************@planet.nlwrote in message
news:O1**************@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" <ac**********@a-znet.comschreef in bericht
news:uG*************@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

"RobinS" <Ro****@NoSpam.yah.nonewrote in message
news:of******************************@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:of******************************@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

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" <ro********@yahoo.comschreef in bericht
news:11*********************@v33g2000cwv.googlegro ups.com...

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

>"RobinS" <Rob...@NoSpam.yah.nonewrote in message

news:of******************************@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

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:11*********************@v33g2000cwv.go oglegroups.com...

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

"RobinS" <Rob...@NoSpam.yah.nonewrote in message

>news:of******************************@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

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

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]" <no************@planet.nlwrote in message
news:%2****************@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" <ro********@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" <du******@gmail.comwrote in message
news:11**********************@b75g2000hsg.googlegr oups.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

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

"rowe_newsgroups" <rowe_em...@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 the confirmations Michael.

Thanks,

Seth Rowe

"Chris Dunaway" <du******@gmail.comwrote in message
news:11**********************@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" <ro********@yahoo.comschreef in bericht
news:11*********************@c51g2000cwc.googlegro ups.com...

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:11*********************@v33g2000cwv.g ooglegroups.com...

On Mar 13, 2:56 am, "Michael C" <nos...@nospam.comwrote:
"RobinS" <Rob...@NoSpam.yah.nonewrote in message

>>news:of******************************@comcast.co m...

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

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 Ligthert [MVP]" <no************@planet.nlwrote in message
news:e%****************@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" <no****@nospam.comschreef in bericht
news:%2****************@TK2MSFTNGP06.phx.gbl...

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:e%****************@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

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:%2****************@TK2MSFTNGP06.phx.gb l...

"Cor Ligthert [MVP]" <notmyfirstn...@planet.nlwrote in message
news:e%****************@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

"Michael C" <no****@nospam.comwrote in message
news:uh**************@TK2MSFTNGP02.phx.gbl...

"Chris Dunaway" <du******@gmail.comwrote in message
news:11**********************@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

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:11**********************@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.

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:

"Chris Dunaway" <dunaw...@gmail.comwrote in message

news:11**********************@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.

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

No do you?

Cor

"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@l77g2000hsb.googlegr oups.com...

>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:%2****************@TK2MSFTNGP06.phx.g bl...

"Cor Ligthert [MVP]" <notmyfirstn...@planet.nlwrote in message
news:e%****************@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

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" <ac**********@a-znet.comschreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl...

>
"Michael C" <no****@nospam.comwrote in message
news:uh**************@TK2MSFTNGP02.phx.gbl...

>"Chris Dunaway" <du******@gmail.comwrote in message
news:11**********************@b75g2000hsg.googleg roups.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

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?

No do you?

It's difficult to know what you're replying to as you didn't quite me
before your response, but I'm guessing you're asking if I know the
inner implementation details of a Label's dispose method. And the
answer is of course not. With that said I can think of three things
that could be happening inside the Dispose method:

1) It does nothing
2) It does something beneficial
3) It does something detrimental

In case 1 calling Dispose would at least prevent it from going through
2 cycles of garbage collection. So why not call Dispose here?

In case 2 calling Dispose would help out the program. So why not call
Dispose here?

In case 3 calling Dispose would hurt the program's performance, but we
know that eventually the GC will call it's finallizer, which will most
likely call it's Dispose method, which will still give us the same
performance hit at a later time. At least we can control when the
detrimental effects happen versus waiting for the GC to run (which
happens when it needs to - which is normally when the application is
doing heavy processing - so the further hit from Disposing of the
Label then would further decrease performance). So why not call
Dispose here?

Have I convinced you yet that calling Dispose on a Label is not
pointless?

Thanks,

Seth Rowe
On Mar 14, 1:39 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

No do you?

Cor

"rowe_newsgroups" <rowe_em...@yahoo.comschreef in berichtnews:11**********************@l77g2000hsb.g ooglegroups.com...

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:%2****************@TK2MSFTNGP06.phx.gb l...

"Cor Ligthert [MVP]" <notmyfirstn...@planet.nlwrote in message
news:e%****************@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

Can someone explain this test result?

It shows the open dialog twice.

After the Dispose I wouldn't expect the box was still useful

Unless the Dispose does nothing

If so why have it?

Anyone know what is going on here?

GC.Collect()

OpenFileDialog1.ShowDialog()

OpenFileDialog1.Dispose()

GC.Collect()

OpenFileDialog1.ShowDialog()

Seth,

In what time is the garbage collector working?

Exactly in idle time. And that is very often therefore it is so nice that
that is proven in this thread with a sample that forms mostly very quick
gone after closing.

But how can somebody find benifictal things in processes that is working in
the time as the processor is maybe very needed for very important processes.
Sorry, I don't understand that.

Cor

"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:11**********************@n76g2000hsh.googlegr oups.com...

>No do you?

It's difficult to know what you're replying to as you didn't quite me
before your response, but I'm guessing you're asking if I know the
inner implementation details of a Label's dispose method. And the
answer is of course not. With that said I can think of three things
that could be happening inside the Dispose method:

1) It does nothing
2) It does something beneficial
3) It does something detrimental

In case 1 calling Dispose would at least prevent it from going through
2 cycles of garbage collection. So why not call Dispose here?

In case 2 calling Dispose would help out the program. So why not call
Dispose here?

In case 3 calling Dispose would hurt the program's performance, but we
know that eventually the GC will call it's finallizer, which will most
likely call it's Dispose method, which will still give us the same
performance hit at a later time. At least we can control when the
detrimental effects happen versus waiting for the GC to run (which
happens when it needs to - which is normally when the application is
doing heavy processing - so the further hit from Disposing of the
Label then would further decrease performance). So why not call
Dispose here?

Have I convinced you yet that calling Dispose on a Label is not
pointless?

Thanks,

Seth Rowe
On Mar 14, 1:39 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

>No do you?

Cor

"rowe_newsgroups" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@l77g2000hsb. googlegroups.com...

>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:%2****************@TK2MSFTNGP06.phx.g bl...

"Cor Ligthert [MVP]" <notmyfirstn...@planet.nlwrote in message
news:e%****************@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

active,

The GC runs on a seperated thread.

Cor

" active" <ac**********@a-znet.comschreef in bericht
news:uz**************@TK2MSFTNGP06.phx.gbl...

Can someone explain this test result?

It shows the open dialog twice.

After the Dispose I wouldn't expect the box was still useful

Unless the Dispose does nothing

If so why have it?

Anyone know what is going on here?

GC.Collect()

OpenFileDialog1.ShowDialog()

OpenFileDialog1.Dispose()

GC.Collect()

OpenFileDialog1.ShowDialog()

but why does this work
OpenFileDialog1.ShowDialog()
after it has been disposed

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:up**************@TK2MSFTNGP04.phx.gbl...

active,

The GC runs on a seperated thread.

Cor

" active" <ac**********@a-znet.comschreef in bericht
news:uz**************@TK2MSFTNGP06.phx.gbl...

>Can someone explain this test result?

It shows the open dialog twice.

After the Dispose I wouldn't expect the box was still useful

Unless the Dispose does nothing

If so why have it?

Anyone know what is going on here?

GC.Collect()

OpenFileDialog1.ShowDialog()

OpenFileDialog1.Dispose()

GC.Collect()

OpenFileDialog1.ShowDialog()

In what time is the garbage collector working?

>
Exactly in idle time.

Where is that in the documentation?

Thanks,

Seth Rowe
On Mar 14, 3:12 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

Seth,

In what time is the garbage collector working?

Exactly in idle time. And that is very often therefore it is so nice that
that is proven in this thread with a sample that forms mostly very quick
gone after closing.

But how can somebody find benifictal things in processes that is working in
the time as the processor is maybe very needed for very important processes.
Sorry, I don't understand that.

Cor

"rowe_newsgroups" <rowe_em...@yahoo.comschreef in berichtnews:11**********************@n76g2000hsh.g ooglegroups.com...

No do you?

It's difficult to know what you're replying to as you didn't quite me
before your response, but I'm guessing you're asking if I know the
inner implementation details of a Label's dispose method. And the
answer is of course not. With that said I can think of three things
that could be happening inside the Dispose method:

1) It does nothing
2) It does something beneficial
3) It does something detrimental

In case 1 calling Dispose would at least prevent it from going through
2 cycles of garbage collection. So why not call Dispose here?

In case 2 calling Dispose would help out the program. So why not call
Dispose here?

In case 3 calling Dispose would hurt the program's performance, but we
know that eventually the GC will call it's finallizer, which will most
likely call it's Dispose method, which will still give us the same
performance hit at a later time. At least we can control when the
detrimental effects happen versus waiting for the GC to run (which
happens when it needs to - which is normally when the application is
doing heavy processing - so the further hit from Disposing of the
Label then would further decrease performance). So why not call
Dispose here?

Have I convinced you yet that calling Dispose on a Label is not
pointless?

Thanks,

Seth Rowe

On Mar 14, 1:39 pm, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

No do you?

Cor

"rowe_newsgroups" <rowe_em...@yahoo.comschreef in
berichtnews:11**********************@l77g2000hsb.g ooglegroups.com...

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:%2****************@TK2MSFTNGP06.phx.gb l...

"Cor Ligthert [MVP]" <notmyfirstn...@planet.nlwrote in message
news:e%****************@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

"rowe_newsgroups" <ro********@yahoo.comschrieb:

It's difficult to know what you're replying to as you didn't quite me
before your response, but I'm guessing you're asking if I know the
inner implementation details of a Label's dispose method. And the
answer is of course not. With that said I can think of three things
that could be happening inside the Dispose method:

1) It does nothing
2) It does something beneficial
3) It does something detrimental

In case 1 calling Dispose would at least prevent it from going through
2 cycles of garbage collection. So why not call Dispose here?

In case 2 calling Dispose would help out the program. So why not call
Dispose here?

In case 3 calling Dispose would hurt the program's performance, but we
know that eventually the GC will call it's finallizer, which will most
likely call it's Dispose method, which will still give us the same
performance hit at a later time.

I fully agree. Especially if 'Dispose' does nothing, then calling it
doesn't hurt the program's performance much.

The rule I am following is that calling 'Dispose' too often causes less
problems than not calling it at all.

At least we can control when the
detrimental effects happen versus waiting for the GC to run (which
happens when it needs to - which is normally when the application is
doing heavy processing - so the further hit from Disposing of the
Label then would further decrease performance). So why not call
Dispose here?

Have I convinced you yet that calling Dispose on a Label is not
pointless?

It depends on the specific situation. In general you need to call 'Dispose'
only on objects you created. In addition, adding a control to a form will
cause it to be disposed automatically if the parent form gets disposed. So
it is not necessary to remove all the controls from the form and call their
'Dispose' method.

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

Cor,

"Cor Ligthert [MVP]" <no************@planet.nlschrieb:

In what time is the garbage collector working?

Exactly in idle time. And that is very often therefore it is so nice that
that is proven in this thread with a sample that forms mostly very quick
gone after closing.

Will this help if your system hangs because your applications holds lots of
GDI handles, for example, and the GC does not know that they can be freed
because the objects holding them have to wait some collection generations
for their disposal and finalization?

The main problem is not performance, it's that the CLR/GC does not know
anything about unmanaged resources. That's why the GC is useless when
dealing with unmanaged resources and why we have to provide functionality to
release unmanaged resources in time. The GC knows nothing about the
semantics of a class, but this knowledge is required to release the
unmanaged resources which are not needed any more by your application.

But how can somebody find benifictal things in processes that is working
in the time as the processor is maybe very needed for very important
processes. Sorry, I don't understand that.

As I said, I believe that the performance argument doesn't count nowadays as
it did some years ago. Calling 'Dispose' is a "constant factor" that can be
ignored. Choosing ideal data structures etc. will help much more to make an
application faster. If performance would still count, we would not use the
blown up .NET Framework's classes to write Windows applications, for
example.

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

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>I can call thousands but just one

Label?

Label uses a window handle so is most definately a finite resource that
needs to be disposed. In fact it is a very good example of why dispose is
implemented because a form could potentially have a large number of labels
using up a large number of windows handles. So please try again. :-)

Michael

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:ur**************@TK2MSFTNGP04.phx.gbl...

No do you?

I don't know all the details but I know some. When you create a label object
it creates a window handle. When you call dispose it destroys the window
handle. But that is not relevant. The point of implementing IDiposable is
that I don't need to know the implementation, just that Dispose should be
called asap.

Michael

"rowe_newsgroups" <ro********@yahoo.comschrieb:

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

I agee. Speaking more generally, interfaces are contracts. If a class (or
one of its derived classes, which one does not matter) implements
'IDisposable', this means "I cannot guarantee that I will never need
unmanaged resources". Even if the current implementation does not use
unmanaged resources, by implementing the interface it indicates that this is
not guaranteed. Imagine even the case that another implementation of the
class than those contained in the .NET Framework may actually use unmanaged
resources and thus calling 'Dispose' makes perfect sense.

Unfortunately developers even nowadays spend a lot of time on
micro-optimizations which are often "unclean" hacks which will work on their
system, using a certain implementation, ..., but which are
counter-productive from the long-term perspective.

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?

I don't think such an example exists (if the call is performed if the object
is not in use any more) because a method call is done quickly and its better
to do it sooner than later in order to prevent a resource bottleneck.

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

Michael,

In my opinion are you all the time talking about finalizing and calls it
dispose.

There is no name shift in Net. Dispose is something else than finalizing.

Dispose is to give unmanaged resources to the GC.

Cor

"Michael C" <no****@nospam.comschreef in bericht
news:eY**************@TK2MSFTNGP06.phx.gbl...

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>>I can call thousands but just one

Label?

Label uses a window handle so is most definately a finite resource that
needs to be disposed. In fact it is a very good example of why dispose is
implemented because a form could potentially have a large number of labels
using up a large number of windows handles. So please try again. :-)

Michael

Herfried,

I agee. Speaking more generally, interfaces are contracts. If a class
(or one of its derived classes, which one does not matter) implements
'IDisposable', this means "I cannot guarantee that I will never need
unmanaged resources". Even if the current implementation does not use
unmanaged resources, by implementing the interface it indicates that this
is not guaranteed.

But implementing IDisposable means direct that there is no need to call
dispose for all child members.
While we see that the sample implementation shows forever component in the
implementation.

However this combinantion gives direct the method dispose to every child and
a kind of foolish talking from people not knowing what to do on Internet
became populair.

"If you don't know why something is, than use it. I probably does not hurt"

Somebody who tells or write this in programming shows for me that he is an
absolute amateur.

Cor




Imagine even the case that another implementation of the

class than those contained in the .NET Framework may actually use
unmanaged resources and thus calling 'Dispose' makes perfect sense.

Unfortunately developers even nowadays spend a lot of time on
micro-optimizations which are often "unclean" hacks which will work on
their system, using a certain implementation, ..., but which are
counter-productive from the long-term perspective.

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

I don't think such an example exists (if the call is performed if the
object is not in use any more) because a method call is done quickly and
its better to do it sooner than later in order to prevent a resource
bottleneck.

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

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:uc**************@TK2MSFTNGP04.phx.gbl...

Michael,

In my opinion are you all the time talking about finalizing and calls it
dispose.

No.

There is no name shift in Net. Dispose is something else than finalizing.

I know. I am talking about Dispose.

Dispose is to give unmanaged resources to the GC.

No it doesn't. It gives unmanaged resources back to the system, not the GC.

I'm guessing by the fact that you didn't come up with another example that
you couldn't.

Michael

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:ev**************@TK2MSFTNGP06.phx.gbl...

"If you don't know why something is, than use it. I probably does not
hurt"

Somebody who tells or write this in programming shows for me that he is an
absolute amateur.

Odd that you would call other's here foolish when you've pretty much out on
your own with your opinions.

The point is that these programmers know when they don't need to know, which
is the whole point of IDisposable. You don't need to know it uses unmanaged
resources or not, all you need to know is that you should dispose an object
once finished with it *if* it has IDisposable interface.

Michael

Michael,

I'm guessing by the fact that you didn't come up with another example that
you couldn't.

What you want me to do, proof that you are right in this discussion, I tell
all the time that dispose is only implemented in by instance label because
label is (somewhere in the base) inherited from Component. It is not ment to
use.

Almost the same is with the Text property in a picturebox. It does nothing,
it is there because Control has Text..

Cor

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

I can call thousands but just one

Label?

Cor

Cor,

That really depends. A label is a windowed control in .NET - and
because of that it holds an hWnd. An hwnd is an OS allocated handle -
and that is a finite resource, and is unmanaged.

Usually, i dispose of dialog windows when done with them.

using (SomeDialog someDialog = new SomeDialog ())
{
if (someDialog.ShowDialog (this) == DialogResult.Ok)

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

I can call thousands but just one

Label?

Cor

I hope you can ignore the partial response... I accidently hit
send :) Anyway, the point of that oh, so obnoxious C# code was that I
believe with forms/usercontrols/etc - you should probably call dispose
(especiall if they are dynamically created/removed).

Will it be critical to most applications? No. Probably not. Most
will be just fine - but, then again, some won't - and may start
generating out of handle errors :)

--
Tom Shelton

On Mar 15, 12:15 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl>
wrote:

Michael,

I'm guessing by the fact that you didn't come up with another example that
you couldn't.

What you want me to do, proof that you are right in this discussion, I tell
all the time that dispose is only implemented in by instance label because
label is (somewhere in the base) inherited from Component. It is not ment to
use.

Almost the same is with the Text property in a picturebox. It does nothing,
it is there because Control has Text..

Cor

Cor - labels .Dispose most definately does something. I suggest you
get out Reflector and follow the chain.... HINT: It eventually
releases the window handle (a finite unmanaged system resource).

--
Tom Shelton

On Mar 13, 12:32 am, "RobinS" <Rob...@NoSpam.yah.nonewrote:

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

Robin S.

Definately... The fact that you can still reference controls after
the showdialog has returned (like through a property of the form)
shows that the form is still alive - along with all it's handles. I
usually show dialogs in a Using block (well using since I use C# most
of the time :).

--
Tom Shelton

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:ug**************@TK2MSFTNGP04.phx.gbl...

What you want me to do, proof that you are right in this discussion, I
tell all the time that dispose is only implemented in by instance label
because label is (somewhere in the base) inherited from Component.

That's just plain wrong. Label has a dispose method because it is a wrapper
around an unmanaged resource.

It is not ment to use.

It is most definately meant to be used, it is just used for you.

Almost the same is with the Text property in a picturebox. It does
nothing, it is there because Control has Text..

I really wish I had a name for this. "My dog has 4 legs, therefore anything
with 4 legs is a dog, therefore my table is a dog". Just because picturebox
has an useless Text property does that somehow magically mean all inherited
properties or methods are useless.

Michael

"Tom Shelton" <to*********@comcast.netwrote in message
news:11**********************@b75g2000hsg.googlegr oups.com...

I hope you can ignore the partial response... I accidently hit
send :) Anyway, the point of that oh, so obnoxious C# code was that I
believe with forms/usercontrols/etc - you should probably call dispose
(especiall if they are dynamically created/removed).

From what I can tell you only need to do it if they a dynamically created
for controls.

Michael

Hii

For closing a form u can use

me.close();
OR
me.dispose();

or if u want to close the full application then also u can write this on
the parent form but that is not a good idea,
because due to that process's for that application will run. or we can
say that some internal processes u can see in task manager for that
application. So to avois that situation we can write End whereever
we want to close the application. This will end the whole process for
that application.

So here we go......

Nitin Sharma NXS

*** Sent via Developersdex http://www.developersdex.com ***