Does it make sense in FormClosed to do Me.Dispose

  • Thread starter Thread starter pvdg42
  • Start date Start date
Cor Ligthert said:
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.
Click to expand...

I know. I am talking about Dispose.
Dispose is to give unmanaged resources to the GC.
Click to expand...

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 said:
"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.
Click to expand...

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.
Click to expand...
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
 
I can call thousands but just one

Label?

Cor
Click to expand...

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)
 
I can call thousands but just one

Label?

Cor
Click to expand...

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 :)
 
Michael,


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
Click to expand...

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).
 
I agree; I have heard that one should dispose of any forms that you do a
ShowDialog() on.

Robin S.
Click to expand...

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 :).
 
Cor Ligthert said:
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.
Click to expand...

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.
Click to expand...

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..
Click to expand...

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 said:
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).
Click to expand...

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

For closing a form u can use

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

sometimes u can also use me.hide() for hiding that form.

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
 
"If you don't know why something is, than use it. I probably does not hurt"

Cor, who said this? I've shown you that there are 3 general things
that dispose can do, and all in three situations calling Dispose
manually is better than letting the GC call it's Finalize and Dispose
methods. The only thing you argued is that the GC only runs in idle
time, on a separate thread - and you still haven't shown me the
documentation that proves this, so I'm starting to wonder if it
exists?

Thanks,

Seth Rowe


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.
Click to expand...

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.
Click to expand...
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.
Click to expand...
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.
Click to expand...
Click to expand...
 
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.
Click to expand...

Cor, multiple people have shown you why it is important to Dispose of
labels, why are you still insisting that it is pointless? Are they
wrong about the window handles needing to be released?

Thanks,

Seth Rowe
 
Cor Ligthert said:
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.
Click to expand...

If you are talking about 'System.Windows.Forms.Label', 'Dispose' does a lot
of work. It's not only implemented in the base class but also the 'Control'
class and overridden in the 'Label' class. Calling 'Dispose' will release
some objects associated with the control and delete the Win32 control.
Almost the same is with the Text property in a picturebox. It does
nothing, it is there because Control has Text..
Click to expand...

That's IMO something different, as your sample with the 'ToString' method
is. The 'Text' property doesn't fit semantically and the 'ToString'
property is only used for a special purpose. It doesn't make sense to use
it in places in which you do not want a string representation of the object.
'Dispose' simply signals that the class may hold resources until
finalization which can be released at an earlier point.
 
Tom,

The dispose can be used to do overriden actions.

AdoNet has used it in past to remove the physical connection string.

(A question do you still see samples with Dispose on MSDN, while that was in
past often done?)

Cor
 
Seth,

Open the hidden part of your windows form program. There you see the
implementation of IDisposable with the component. That does all disposing
for you including labels. This with the exception of the Dialogforms.

Cor
 
Open the hidden part of your windows form program. There you see the
implementation of IDisposable with the component. That does all disposing
for you including labels. This with the exception of the Dialogforms.
Click to expand...

Yes Cor, I know that - as a matter of fact I mentioned previously in
this thread that the many parent objects dispose it's children in it's
own dispose method. Besides, I thought we were talking about disposing
of dynamically created and removed labels? As those are the only ones
we need to worry about disposing since the generated code will remove
the ones in the control collection.

Also, if removing Labels is pointless and stupid as you have alluded
to, have you written Microsoft to tell them that the generated code is
wrong in disposing of labels and other objects that inherit from
component?

Thanks,

Seth Rowe
 
Back
Top