Must call RemoveHandler after AddHandler?

[Tom]

I use dynamically created controls all the time. I.E. I create the
control in code then use AddHandler to add the necessary delegates for
processing (like Click, etc).

Does one have to call RemoveHandler after processing is done? In other
words, when the form is closing do I have to do a RemoveHandler for
each one of the controls I created? Or can I just let .NET handle it
when the form is closed and garbage collection is done?

Tom
--

 

[Marina Levit [MVP]]

No, you shouldn't have to do anything in the case you are describing.

 

[Tom]

Cool... So basically, when the form is closed and discard, then the
delegates you 'hooked' are automatically taken care of by the .NET
runtime/CLR?

 

[Marina Levit [MVP]]

Had you designated the handlers at design time by adding the 'Handles
objectName.EventName' at the end of a method, you wouldn't be thinking you
need to detach the handler.

AddHandler is just a programmatic way of attaching the handler instead of a
declarative way.

As long as the objects and the event handler methods are all in the user
control or form, when that user control or form is gone, the object should
be eligible for GC, since all the event handler methods are within its own
definition.

 

[tommaso.gastaldi]

It's safe to make sure there is no possibility to re-execute the
AddHandler ... statement (a remove might even precede, just in case...)

Tommaso

Tom ha scritto:

 

[Tom]

Marina: Very good... but let's address what Tommaso mentioned - Let's
say the user closes the form, then immediately re-opens it. And let's
assume that GC hasn't occured yet. If that is the case, would
re-opening the form cause the CLR to just reload the in-memory form,
and then (if this is the case) wouldn't doing the AddHandler again
cause an issue? Or I am completely off-base here?

Tom

 

[tommaso.gastaldi]

As marina has well explained, I would not be much worried
by your scenario. When the form is disposed, the handler is gone.

There are other situations, where one has to watch not to
add the handler multiple times, which could results in errors
usually not straightforward to debug.

About forms, it depends... if the form is modal (.shodialog)
closing the form will not dispose it. So the handler will
still be there awaiting ...

------

In general, especially if code is not to be distributed to dummies, I
feel
that using delegates instead of events is safer and more confortable
(except for some simple cases)

For instance, it is more difficult that you forget to handle calls if
the
function is not set up a null pointer error will readily occur.
Plus, it is not possible to replicate the handling of a call.
Finally, they are readily available by the intellisense...

But that is matter of taste, I guess ...

-tommaso


Tom ha scritto:

 

[Marina Levit [MVP]]

But you would attach the handler on a different instance of that form. The
first instance is not affected. When that item needs to be garbage
collected, it should be, since it doesn't have any handlers on external
objects, just on its own.

 

[Tom]

OK, cool... thanks to both of you for the advice!

 

[Cor Ligthert [MVP]]

About forms, it depends... if the form is modal (.shodialog)
closing the form will not dispose it. So the handler will
still be there awaiting ...

On what?

 

[tommaso.gastaldi]

Hi Cor,

I guess there can be any custom events. Or even interface events that
have been
accumulated. For instance some mouse move (eg., dragging some drawings
that takes time to redraw) which is still firing after a form has been
closed.

Try to make a simple example of "Static" handler. 2 buttons on Form1:
CLICK on Button1,Click on Close (dialog form),CLICK on Button2
Here, one might assume that after close or dispose the handler would
be gone but...

Public Class Form1
Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "
#End Region

Public Shared Event TellMyHi()

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim OtherModal As New OtherModal
With OtherModal
.ShowDialog()
End With
End Sub

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click
RaiseEvent TellMyHi()
End Sub

End Class

Public Class OtherModal
Inherits Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

AddHandler TellMyHi, AddressOf TellMyHi_Handler

Me.Text = "OtherModal"
Me.Button1.Dispose()
Me.Button2.Dispose()

Dim ButtonClose As New Button
Me.Controls.Add(ButtonClose)
ButtonClose.Text = "Close"
AddHandler ButtonClose.Click, AddressOf Me.Bye
End Sub

Sub TellMyHi_Handler()
MsgBox("Greetings from OtherModal")
End Sub

Sub Bye(ByVal sender As System.Object, ByVal e As System.EventArgs)
Me.Close()
End Sub

End Class


Cor Ligthert [MVP] ha scritto:

 

[Cor Ligthert [MVP]]

tommasso,

Are you real making programs like this, inheriting the mainform inside a
modal form and than use the event from the mainform to handle something.

It seems for me a very complex construction, but you are right, in this case
the event is still handled.

Thanks for showing the sample by the way.

Cor

 

[tommaso.gastaldi]

Hi Cor,
No. As I said I don't even use addhandler usually. This was a 30 sec
example
I just write down to respond to your concise question. But if you wish
I can make some more meaningful one. Actually any user event handled
by a modal for will do ... In the specific case the event continues to
be handled
even if the modal form is *disposed * of. (I wanted to show an extreme
case )

-tom

Cor Ligthert [MVP] ha scritto: