Does it make sense in FormClosed to do Me.Dispose

  • Thread starter Thread starter pvdg42
  • Start date Start date
Multiple means here 2.

So you're admitting that 2 people have shown you that it makes sense?
Far more people have showed me that it is without sense.
Click to expand...

Ok, who might they be and what were their arguments that it is
senseless?

Thanks,

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

Yes - I went a little to far. For instance, you don't need to call
dispose on controls sited on a form - because when the form is
disposed it will dispose the children. Really, the only things you
need to worry about are controls that are being removed from the form
in a dynamic fashion or dialog forms...
 
active said:
So immediately after I do a dispose I might still be able to access the
object. That's a surprise.

I understand that the GC may not happen for some time but it's anybody
guess what dispose may have done to the object.

Just to refresh, the original question was why does the second
OpenFileDialog work after the object has been disposed. The GC lines were
only there because I did cut - paste.
Click to expand...

'OpenFileDialog' inherits 'Dispose' from its 'Component' base type but does
not override it. The implementation in 'Component' looks as follows
(according to Reflector):

\\\
Protected Overridable Sub Dispose(ByVal disposing As Boolean)
If disposing Then
SyncLock Me
If _
( _
(Not Me.site Is Nothing) AndAlso _
(Not Me.site.Container Is Nothing) _
) _
Then
Me.site.Container.Remove(Me)
End If
If (Not Me.events Is Nothing) Then
Dim handler1 As EventHandler = _
DirectCast( _
Me.events.Item(Component.EventDisposed), _
EventHandler _
)
If (Not handler1 Is Nothing) Then
handler1.Invoke(Me, EventArgs.Empty)
End If
End If
End SyncLock
End If
End Sub
///

.... which does not prevent the dialog from working. It only disconnects it
from its container.

However, I recommend to call 'Dispose' here too because an implementation on
another operating system than Windows may add custom disposing code.
 
So immediately after I do a dispose I might still be able to access the
object. That's a surprise.

I understand that the GC may not happen for some time but it's anybody guess
what dispose may have done to the object.

Just to refresh, the original question was why does the second
OpenFileDialog work after the object has been disposed. The GC lines were
only there because I did cut - paste.


Thanks, as always, for replying
 
Herfried K. Wagner said:
'OpenFileDialog' inherits 'Dispose' from its 'Component' base type but
does not override it. The implementation in 'Component' looks as follows
(according to Reflector):

\\\
Protected Overridable Sub Dispose(ByVal disposing As Boolean)
If disposing Then
SyncLock Me
If _
( _
(Not Me.site Is Nothing) AndAlso _
(Not Me.site.Container Is Nothing) _
) _
Then
Me.site.Container.Remove(Me)
End If
If (Not Me.events Is Nothing) Then
Dim handler1 As EventHandler = _
DirectCast( _
Me.events.Item(Component.EventDisposed), _
EventHandler _
)
If (Not handler1 Is Nothing) Then
handler1.Invoke(Me, EventArgs.Empty)
End If
End If
End SyncLock
End If
End Sub
///

... which does not prevent the dialog from working. It only disconnects
it from its container.

However, I recommend to call 'Dispose' here too because an implementation
on another operating system than Windows may add custom disposing code.
Click to expand...


I'm guess that I should only dispose if it is not added by the Designer,
right?

And if I do dispose I don't do it until the last usage, right?


Thanks a lot
 
rowe_newsgroups said:
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?
Click to expand...

Cor just doesn't want to admit he is wrong. You need to call dispose, this
is very well known and not in dispute.

Michael
 
Michael,

Try this and give than a honest answer.
You said a label has to be disposed.

This sample I made for the question Override.

I expect that I get an answer that I don't understand it and my English is
not good enough, be aware however I am not the only reader in this
newsgroup.

\\\
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim myLabel As New MyBaseLabel
Me.Controls.Add(myLabel)
End Sub
////
Just add this class under the end class of the form
\\\\
Public Class MyBaseLabel
Inherits System.Windows.Forms.TextBox
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
MessageBox.Show("The label is disposing")
End If
MyBase.Dispose(disposing)
End Sub
End Class
///
 
Cor Ligthert said:
Michael,

Try this and give than a honest answer.
You said a label has to be disposed.

This sample I made for the question Override.

I expect that I get an answer that I don't understand it and my English is
not good enough, be aware however I am not the only reader in this
newsgroup.
Click to expand...

Maybe I misunderstood what you're trying to say. Any object that has a
Dispose method should have Dispose called. However, in the case of labels
Dispose is called for you, so you don't need to explicitly call it yourself.
If you remove the label from the form manually then I believe you need to
call dispose because it will not be done for you.

Michael
 
Michael,

Try this and give than a honest answer.
You said a label has to be disposed.

This sample I made for the question Override.

I expect that I get an answer that I don't understand it and my English is
not good enough, be aware however I am not the only reader in this
newsgroup.

\\\
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim myLabel As New MyBaseLabel
Me.Controls.Add(myLabel)
End Sub
////
Just add this class under the end class of the form
\\\\
Public Class MyBaseLabel
Inherits System.Windows.Forms.TextBox
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
MessageBox.Show("The label is disposing")
End If
MyBase.Dispose(disposing)
End Sub
End Class
///
Click to expand...

Cor, we've already talked about this behavior and stated that it
wasn't what we were talking about. We know that the form disposes of
the objects in it's controls collection automatically, we were talking
about the need to dispose of dynamically removed controls (or one's
that aren't present in the control collection of a parent object)

Besides, doesn't your example show that it is a good practice to
dispose of the label as the function is present by design? After all
if the designers (who probably know the inner working of the controls)
dispose of these controls when they remove them, shouldn't we do the
same?

Thanks,

Seth Rowe
 
Cor,

Cor Ligthert said:
\\\\
Public Class MyBaseLabel
Inherits System.Windows.Forms.TextBox
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
MessageBox.Show("The label is disposing")
End If
MyBase.Dispose(disposing)
End Sub
End Class
///
Click to expand...

Be aware that messageboxes shown from the 'Dispose' method are not always
shown although the lines are executed. It's more secure to set a breakpoint
or use a 'Stop' statement for debugging purposes.
 
Herfried,

Do you really think that I will use this kind of programming, it is only to
show that forms implements Idisposable and therefore that what is placed on
it will be disposed without manual handling from the programmer. That I have
written in this thread, but is consequently denied.

Some of the messages written not by me.
Cor just doesn't want to admit he is wrong. You need to call dispose, this
is very well known and not in dispute.
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?
Click to expand...
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.
Click to expand...

Cor
 
Do you really think that I will use this kind of programming, it is only to
show that forms implements Idisposable and therefore that what is placed on
it will be disposed without manual handling from the programmer. That I have
written in this thread, but is consequently denied.
Click to expand...

As far as I can tell, no one is denying that forms dispose of their
child controls? As a matter of fact I have stated this 3 times in this
thread!

Again, we are talking about the need to dispose of controls that we
remove from a form before the form is disposed.

i.e.

' Typed in message

private sub Foo()
Dim myLabel as new Label()
myForm.Controls.Add(myLabel)
myForm.Controls.Remove(myLabel)
myLabel.Dispose()
end sub

So do you understand what we are talking about now?

Thanks,

Seth Rowe


Herfried,

Do you really think that I will use this kind of programming, it is only to
show that forms implements Idisposable and therefore that what is placed on
it will be disposed without manual handling from the programmer. That I have
written in this thread, but is consequently denied.

Some of the messages written not by me.
Cor just doesn't want to admit he is wrong. You need to call dispose, this
is very well known and not in dispute.
Cor, multiple people have shown you why it is important to Dispose of
labels, why are you still insisting that it is pointless?
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.
Click to expand...

Cor

Herfried K. Wagner said:
Cor,
Click to expand...
Be aware that messageboxes shown from the 'Dispose' method are not always
shown although the lines are executed. It's more secure to set a
breakpoint or use a 'Stop' statement for debugging purposes.
Click to expand...
Click to expand...
 
Back
Top