469,604 Members | 2,381 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,604 developers. It's quick & easy.

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

Aug 8 '06 #1
12 6512
No, you shouldn't have to do anything in the case you are describing.

"Tom" <to*@nospam.comwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
>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
--

Aug 8 '06 #2
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] wrote:
>No, you shouldn't have to do anything in the case you are describing.

"Tom" <to*@nospam.comwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
>>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
--
Aug 8 '06 #3
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.

"Tom" <to*@nospam.comwrote in message
news:uM**************@TK2MSFTNGP04.phx.gbl...
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] wrote:
>>No, you shouldn't have to do anything in the case you are describing.

"Tom" <to*@nospam.comwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
>>>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
--

Aug 8 '06 #4
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:
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] wrote:
No, you shouldn't have to do anything in the case you are describing.

"Tom" <to*@nospam.comwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
>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
--
Aug 8 '06 #5
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
--

Marina Levit [MVP] wrote:
>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.

"Tom" <to*@nospam.comwrote in message
news:uM**************@TK2MSFTNGP04.phx.gbl...
>>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] wrote:
>>>No, you shouldn't have to do anything in the case you are
describing.

"Tom" <to*@nospam.comwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl.. .
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
--
Aug 8 '06 #6
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: 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
--

Marina Levit [MVP] wrote:
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.

"Tom" <to*@nospam.comwrote in message
news:uM**************@TK2MSFTNGP04.phx.gbl...
>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] wrote:

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

"Tom" <to*@nospam.comwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
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
--
Aug 8 '06 #7
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" <to*@nospam.comwrote in message
news:OR**************@TK2MSFTNGP03.phx.gbl...
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
--

Marina Levit [MVP] wrote:
>>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.

"Tom" <to*@nospam.comwrote in message
news:uM**************@TK2MSFTNGP04.phx.gbl...
>>>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] wrote:

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

"Tom" <to*@nospam.comwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl. ..
>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
>--

Aug 8 '06 #8
Tom
OK, cool... thanks to both of you for the advice!
--

Marina Levit [MVP] wrote:
>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" <to*@nospam.comwrote in message
news:OR**************@TK2MSFTNGP03.phx.gbl...
>>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
--
Marina Levit [MVP] wrote:
>>>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.

"Tom" <to*@nospam.comwrote in message
news:uM**************@TK2MSFTNGP04.phx.gbl...
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] wrote:

>No, you shouldn't have to do anything in the case you are
>describing.
>
>"Tom" <to*@nospam.comwrote in message
>news:%2***************@TK2MSFTNGP06.phx.gbl.. .
>>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
>>--
Aug 8 '06 #9
>
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?

Aug 9 '06 #10
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:

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?
Aug 9 '06 #11
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

<to**************@uniroma1.itschreef in bericht
news:11**********************@75g2000cwc.googlegro ups.com...
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:
>
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?

Aug 9 '06 #12
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:
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

<to**************@uniroma1.itschreef in bericht
news:11**********************@75g2000cwc.googlegro ups.com...
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:

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?
Aug 11 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by teo | last post: by
1 post views Thread by Urs Vogel | last post: by
22 posts views Thread by Ricky W. Hunt | last post: by
3 posts views Thread by hartley_aaron | last post: by
reply views Thread by =?Utf-8?B?xJBvbm55?= | last post: by
4 posts views Thread by Sid Price | last post: by
reply views Thread by guiromero | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.