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
--
12  7100 
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
--
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
--
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
--
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
--
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
--
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
--
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
>--
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
>>--
>
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?
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?
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?
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?
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: teo |
last post by:
Hallo,
I have used many time the AddHandler method (becuse I'm
buildin an array of controls).
Now I 'd like to know if I have to use the
RemoveHandler method.
In fact I use the array of...
|
by: Patrick.O.Ige |
last post by:
Hi All
i'm getting error with my TreeView Menu(I want to have a button with
ExpandALL and CollapseALL):-
Error:-
'AddressOf' operand must be the name of a method; no parentheses are needed.
I...
|
by: Urs Vogel |
last post by:
Hi
I need to detect wether an event handler has been added to an (Word object
Quit) event.
Question 1: How do I look up the event handler queue of an event, either
native .Net or COM interop?...
|
by: Atara |
last post by:
regarding the answers I got from the thread
"Does each "New" needs a corresponding "Dispose" "
(http://www.developersdex.com/vb/message.asp?p=&r=3582570&page=2)
I have some questions:
Till now,...
|
by: Ricky W. Hunt |
last post by:
First, the subject probably doesn't use the correct terms but I'm not sure
what it's called in VB.
I'm writing a media player app. The subroutine that handles the "open file"
button contains an...
|
by: Gary Kahrau |
last post by:
If I create a form dynamically, is there some way I can point to a dll
function/ sub when the dynamic button is pushed?
Or do something like this.
dim DynSub as string
DynSub = "DoItSub" ...
|
by: hartley_aaron |
last post by:
Hi,
I was trying to store the address of the my current handler for a
particular event so as to simplify using AddHandler and RemoveHandler
throughout my code. However, I cannot seem to get any...
|
by: =?Utf-8?B?xJBvbm55?= |
last post by:
Hi, I think I understand why it behaves how it behaves.
A new feature of VB9 allows you to AddHandler for methods with slightly
different signatures than signature of event is. However as I...
|
by: Sid Price |
last post by:
I have a compiler warning I do not understand how to fix. I am trying to
remove an event handler and get the following message:
Warning 1 The 'AddressOf' expression has no effect in this context...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
