Well, almost 100% ...
It's tantalisingly close, but there is still one slight gap.
The article shows how to find methods on a receiver that match the pattern
OnXXXX given the sender. It loops through the sender events and tries to get
methods from the receiver that match the pattern. For each one it finds it
either adds or removes a handler for the event.
This is great where there is a straight forward mapping, but I don't have a
straight forward mapping. For example, although I could easily use this
pattern in many cases, there are situations where the sender has two similar
events, only one of which a particular receiver is going to service.
Let's say that my sender has an event ValueChanged. My receiver could easily
have a method OnValueChanged that could be linked up using the technique
above. As it happens, my receiver has a method MyControl_ValueChanged, but
this also works with the technique above.
The problem arises where my sender has two values that can change. In this
case it can raise two events: Value1Changed and Value2Changed. My receiver
only services one of these, and which one is determined at runtime.
Therefore, the receiver still has a method MyControl_ValueChanged, because
it knows nothing of a sender that has two values.
This breaks the pattern, as there is now easy way to transform the event
Value2Changed into the method name MyControl_ValueChanged.
So, ...
I am trying to find a way of looping through the sender's events, as before,
but for each one I want to get the invocation list, and see if my receiver
is in it. Only if it is do I want to remove the handler. I have got this far
<code>
Public Shared Sub RemoveHandlers(ByVal sender As Object, ByVal receiver
As Object)
Dim SenderType As Type
Dim ReceiverType As Type
Dim dlgts() As [Delegate]
SenderType = sender.GetType()
ReceiverType = receiver.GetType()
For Each ei As EventInfo In SenderType.GetEvents()
' For each event that the sender can raise, get the invocation
list
dlgts = sender.Events.Item( *WHAT GOES
HERE?* ).GetInvocationList()
For Each dlgt As [Delegate] In dlgts
If *TEST FOR DELEGATE BEING ON RECEIVER?* Then
ei.RemoveEventHandler(sender, dlgt)
End If
Next dlgt
Next ei
End Sub
</code>
Can you suggest what might replace the capitalised text? Alternatively, can
you think of another wau of achieving the same end?
Thanks.
Charles
[If I can crack this then I will have only two problems remaining, one of
which is a totally random crash, that can occur at any time, at any place,
and cause immediate termination without going through any exception
handlers. I am using the Infragistics UltraWinToolbars, et al]
"yEaH rIgHt" <nospam@haha> wrote in message
news:10*************@corp.supernews.com...
Take a look at this, it might help.
http://www.vbinfozine.com/t_bindevt.shtml
"Charles Law" <bl***@nowhere.com> wrote in message
news:O7**************@TK2MSFTNGP09.phx.gbl... I think I asked the wrong question last time, so I am starting a
separate post to distinguish them.
Take five classes: ClassA and ClassW...Z
ClassA raises five events: Event1...5
ClassW...Z handle some combination of these events. For example
ClassW handles Event1, 2 and 5
ClassX handles Event1, 3 and 4
ClassY handles Event2 and 4
...
At some point, I want to detach ClassX from ClassA, so if I were to
write the code longhand, I would have
RemoveHandler ClassA.Event1, AddressOf ClassX.Event1Handler
RemoveHandler ClassA.Event3, AddressOf ClassX.Event3Handler
RemoveHandler ClassA.Event4, AddressOf ClassX.Event4Handler
This is not so bad for a small number of classes and events, but I
actually have about 30 classes and 50 events. The combinations are too large to
contemplate the longhand approach.
.NET must keep track of what event is linked to what handler somewhere
so that it knows what to call. I am looking for a generic (iterative?) way
to detach handlers from events, given only the source class and target
class. These classes implement interfaces that contain the events and handlers
if that helps.
Can anyone give me any clues?
TIA
Charles