AddHandler/RemoveHandler Clarification (Dynamically created controls)

[MLS]

The documentation on dynamic handlers comes across as abiguous.
Perhaps somebody could help set me straight?

I have a situation where I need to dynamically create several
usercontrols of the same type within a form. This usercontrol has some
events associated with it.

For example:

Private Sub NewThingy()
'TODO clean things up better than this (removehandler and
all...)
tabMain.SelectedTab.Controls.Clear()

Dim oMyControl As New MyControl
tabMain.SelectedTab.Controls.Add(oMyControl)

' ... stuff

AddHandler oMyControl.MyEventName, AddressOf MyEventHandler
End Sub

Private Sub MyEventHandler(Parameter as string)
' ... stuff
End Sub

Now, I create four tabs, then call NewThingy within each of them.

So, I now have four instances of MyControl, all pointing at
MyEventHandler.

If one of my instances raises its event, does it fire four times due
to the four AddHandler statements? Or, would it fire only once due to
the fact that oMyControl.MyEventName is only for the one instance of
MyControl?

If I do a RemoveHandler, am I just pulling the first MyEventName off
the stack, am I removing the handler for a specific object instance,
or am I removing all instances of handlers pointing to MyEventName?

I want to be able to create and clean up these handlers properly with
these dynamically created and destroyed controls. Any help would be
appreciated.

Thanks
- mls

[Tom Shelton]

"MLS" <ml*@bitstream.net> wrote in message
news:fd**************************@posting.google.c om...

The documentation on dynamic handlers comes across as abiguous.
Perhaps somebody could help set me straight?

I have a situation where I need to dynamically create several
usercontrols of the same type within a form. This usercontrol has some
events associated with it.

For example:

Private Sub NewThingy()
'TODO clean things up better than this (removehandler and
all...)
tabMain.SelectedTab.Controls.Clear()

Dim oMyControl As New MyControl
tabMain.SelectedTab.Controls.Add(oMyControl)

' ... stuff

AddHandler oMyControl.MyEventName, AddressOf MyEventHandler
End Sub

Private Sub MyEventHandler(Parameter as string)
' ... stuff
End Sub

Now, I create four tabs, then call NewThingy within each of them.

So, I now have four instances of MyControl, all pointing at
MyEventHandler.

If one of my instances raises its event, does it fire four times due
to the four AddHandler statements? Or, would it fire only once due to
the fact that oMyControl.MyEventName is only for the one instance of
MyControl?
It fires once. It just happens that each of the four controls fires the same
method when it needs to raise the event. If you need to know what control
invoked the event, you might consider making your event signature look more like
the standard .NET events. If you look at most event procedures, you will see
something like this:

Private Sub EventHandlerOfSomeKind(ByVal sender As Object, ByVal e As EventArgs)
'
End Sub

The reason they do this is because the object that raised the event passes it
self in the sender parameter:

RaiseEvent EventHandler(Me, E)
If I do a RemoveHandler, am I just pulling the first MyEventName off
the stack, am I removing the handler for a specific object instance,
or am I removing all instances of handlers pointing to MyEventName?
Your basically just removing it for that particular control. You will want to
call RemoveHandler on all controls tied to a particular procedure.
I want to be able to create and clean up these handlers properly with
these dynamically created and destroyed controls. Any help would be
appreciated.

The simple answer is that you should pretty much make sure that you call
RemoveHandler for every AddHandler...

Tom Shelton

[MLS]

"Tom Shelton" <to*@mtogden.com> wrote in
news:eN**************@TK2MSFTNGP11.phx.gbl:

It fires once. It just happens that each of the four controls fires
the same method when it needs to raise the event.

...

Your basically just removing it for that particular control. You will
want to call RemoveHandler on all controls tied to a particular
procedure.

...

Tom Shelton

Thanks Tom, that's how I believed it should work, but was not clear.