Event handling?

[JoshHilton]

Okay, say I have a class named "ChannelList", and it raises an event named "FoundChannel"

But what I'M wanting to do is create multiple classes of different names that use that class, but I want to have all of the "FoundChannel" events be handled under one single sub routine?

Is that possible?

[VBDT]

Yes all the FoundChannel events of all classes must have the same signature. Of example if you define the events as:

Public Event FoundChannel As EventHandler

or

Public Event FoundChannel As EventHandler(Of "the same EventArgs for all")

[JoshHilton]

Well I have been declaring them like this.

Public Event FoundChannel(Channel as ChannelStructure)

[VBDT]

That is fine unless you be consistent through all the events of the classes.

[FourBlades]

If you want to do what you said; that is, have all the events handled under one sub then you do it just like you would with multiple buttons being handled with a single handler:

Public Sub ThisWillHandleAllOfThem(Byval Sender as Object, byval e as EventHandler) _
    Handles Button1.Click, Button2.Click

End Sub

I wouldn't copy that code. I typed it by hand.

[FourBlades]

Public Sub ThisWillHandleAllOfThem(Byval Sender as Object, byval e as EventArgs) _
    Handles Button1.Click, Button2.Click
End Sub

Like I said, don't copy that code...

[VBDT]

FourBlades, if he uses the event signature as he has shown as than the event handler you showed is not going to work because there is no sender in his event signature and the argument is in a structure type.
The correct way of declaring the signature is the way I have showed him. If I were him I would change the structure to Class and inherit it from System.EventArgs class. Than I would use

Public Event FoundChannel As EventHandler(Of "My custom EventArgs")

. here is how to do it right:

Public Class Channel

    Public Event ChannelFound As EventHandler(Of ChannelEventArgs)

    'Some channel properties and methods.
    '...
    '...

    Private Sub FindChanel()
        'some process to find the channel
        '...
        '...

        'Raise on channel found, in this case channel 2.
        Me.OnChannelFound(New ChannelEventArgs(2))
    End Sub

    Protected Overridable Sub OnChannelFound(ByVal e As ChannelEventArgs)
        RaiseEvent ChannelFound(Me, e)
    End Sub

End Class

Create class instead of structure.

Public Class ChannelEventArgs
    Inherits System.EventArgs

    Private _channelNumber As Integer

    Sub New(ByVal channelNumber As Integer)
        Me._channelNumber = channelNumber
    End Sub

    Public ReadOnly Property Channel() As Integer
        Get
            Return Me._channelNumber
        End Get
    End Property
End Class

[Dnereb]

Using a signature like
(Sender as Object, e as ChanelFoundEventArgs)
where ChanelFoundEventArgs inherits of EventArgs is a good convention
although not strictly neccesery.

To solve your polymorpism problem you should use interfaces.

Define an interface Like:

Public Interface IChannelFound

    Event ChannelFound(ByVal sender As Object, ByVal e As ChannelFoundEventArgs)

End Interface

To make the new eventArgs do someting like this:

Public Class ChannelFoundEventArgs

    Inherits EventArgs

    Private _ChannelNumber As Integer

    Property ChannelFound() As Integer
        Get
            Return _ChannelNumber
        End Get
        Set(ByVal value As Integer)
            _ChannelNumber = value
        End Set
    End Property

End Class

Now you can use the interface for several classes, this ensures the signature is correct:

Public Class X
    Implements IChannelFound

    Public Event ChannelFound(ByVal sender As Object, ByVal e As ChannelFoundEventArgs) Implements IChannelFound.ChannelFound

    Sub SomeSub()
        Dim e As New ChannelFoundEventArgs
        e.ChannelFound = 56928
        RaiseEvent ChannelFound(Me, e)
    End Sub
End Class


Public Class Y
    Implements IChannelFound

    Public Event ChannelFound(ByVal sender As Object, ByVal e As ChannelFoundEventArgs) Implements IChannelFound.ChannelFound

    Sub SomeSub()
        Dim e As New ChannelFoundEventArgs
        e.ChannelFound = 1111
        RaiseEvent ChannelFound(Me, e)
    End Sub
End Class

The other benefit is the posibility to cast these classes to the IChannelFound Interface, regardless of the fact that it is a type X class or Type Y class

[VBDT]

Using a signature like
(Sender as Object, e as ChanelFoundEventArgs)
where ChanelFoundEventArgs inherits of EventArgs is a good convention
although not strictly neccesery.

To solve your polymorpism problem you should use interfaces.

Define an interface Like:

Public Interface IChannelFound

    Event ChannelFound(ByVal sender As Object, ByVal e As ChannelFoundEventArgs)

End Interface

To make the new eventArgs do someting like this:

Public Class ChannelFoundEventArgs

    Inherits EventArgs

    Private _ChannelNumber As Integer

    Property ChannelFound() As Integer
        Get
            Return _ChannelNumber
        End Get
        Set(ByVal value As Integer)
            _ChannelNumber = value
        End Set
    End Property

End Class

Now you can use the interface for several classes, this ensures the signature is correct:

Public Class X
    Implements IChannelFound

    Public Event ChannelFound(ByVal sender As Object, ByVal e As ChannelFoundEventArgs) Implements IChannelFound.ChannelFound

    Sub SomeSub()
        Dim e As New ChannelFoundEventArgs
        e.ChannelFound = 56928
        RaiseEvent ChannelFound(Me, e)
    End Sub
End Class


Public Class Y
    Implements IChannelFound

    Public Event ChannelFound(ByVal sender As Object, ByVal e As ChannelFoundEventArgs) Implements IChannelFound.ChannelFound

    Sub SomeSub()
        Dim e As New ChannelFoundEventArgs
        e.ChannelFound = 1111
        RaiseEvent ChannelFound(Me, e)
    End Sub
End Class

The other benefit is the posibility to cast these classes to the IChannelFound Interface, regardless of the fact that it is a type X class or Type Y class

Interface has nothing to do with polymorphism. The example I provided will do the same as yours. Interfaces have other use, that is that you can apply many interfaces to a class but you can inherit only once at the time. Entire dot net classes are written that way, all the event -args inherit from EventArgs class.

[Dnereb]

Yes interface do have to do with polymorphism.

You can cast to the interfaces a class implements...
as well as test with reflection is a class supports a certain interface.
and far more intresting you can use constraints on arguments to be of a certain interface. Thus preventing to pass objects that do not comply to this signature.

For instance a class that Implements Iclonable, Icomparable
Can be cast to these interfaces.

As Said the problem should be solved using an interface to ensure the classes do implement the same methods/events , with the same signature.
This is exactly why interfaces are supposed to be used for.

Furthermore this is far better then keeping track of this manually. Especially if you will need to alter your code 6 to 8 months later...

[VBDT]

Dnereb, I don’t want to mess up this thread by putting stuff here out of context but I think it will clear some confusion about polymorphism. Polymorphism has nothing to do if the class implements interface or not: here is a polymorphism example, consider class A and class B. Class B derives from Class A and class A has a method called ShowValue. Class B overrides the ShowValue of its base class. I declare a variable “theInstance” of Type A and assign it an instance of class B. When I call “theInstance’s” ShowValue I call the class B’s version of the method. This is called polymorphism since the variable I declared is a type of A but since it holds an instance of B it figures out how to call the correct version of ShowValue method that is the B’s version.

And NO the problem should not be solved using interfaces. There is no need for interface. That is unnecessary and the wrong way of doing it. And what happens with inheritance? Why you need to implement an interface in order to have the same methods/events? The inheritance is just for that. I explained in my previous post what is interface for and not going to do in here too.

Here is a polymorphism example:

Public Class Form1
 
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim theInstance As A = New B
        'This will show B's version of ShowValue.
        theInstance.ShowValue()
    End Sub
 
End Class
 
Public Class A
 
    Public Overridable Sub ShowValue()
        MessageBox.Show("Class A")
    End Sub
 
End Class
 
Public Class B
    Inherits A
 
    Public Overrides Sub ShowValue()
        MessageBox.Show("Class B")
    End Sub
End Class

[FourBlades]

VBDT, I'm not sure where we disagreed. I agree with your example.
I thought I was saying the same thing, since when the event is raised the sender is included.

Yes, you should always inherit from EventArgs if you want a custom Class for your event args.

I also would stay away from using an Interface; there's no reason at all to muddy the waters with an interface. I would consider that a misuse of an Interface.

[VBDT]

VBDT, I'm not sure where we disagreed. I agree with your example.
I thought I was saying the same thing, since when the event is raised the sender is included.

No I have no disagreement with you. I just wanted to say that the original way he wanted to declare the event was not going to have sender parameter; it would have only the structure parameter.
It would have only this structure:

Public Class Channel
    Public Event FoundChannel(ByVal channel As ChannelStructure)
 
    Private Sub FindChannel()
        '..
        Dim cs As New ChannelStructure
        cs.cannelNumber = 2
        RaiseEvent FoundChannel(cs) ' No sender argument is allowed
    End Sub
End Class
 
Public Structure ChannelStructure
    Dim cannelNumber As Integer
End Structure

[Dnereb]

somehow I find it very strange to encounter objections against using interfaces. Maybe you can tell me what's wrong with them?

[FourBlades]

1. Interfaces rarely contain a definition for events in the Base Library; that should be a clue.

2. Why define an interface just to Declare a one line Event?

2a. The OP wrote "multiple classes of different names that use that class"
not "multiple variations of a base class."

The OP isn't talking about or using Polymorphism.

Nothing is wrong with using Interfaces where they might be needed.

[Dnereb]

1. Interfaces rarely contain a definition for events in the Base Library; that should be a clue.

That's not an argument that's a bad habbit among a lot of developers.
I for one think you should always write interfaces for classes.
The most important reason is I can use a constraint an an argument that a class needs to support a certain interface. One of the most used interfaces I use is IDirty.

Interface Idirty
IsDirty() as boolean
end interface

this is a contract to indicate user changes to an object.
And I can write a function that checks list(of T as Idirty) to check for altered objects that need to be saved.
The same would apply for interfaces with an event, I do not have an issue with them.

2. Why define an interface just to Declare a one line Event?

Reason 1 is see above. secondly it ensures a better maintainability of your code. Implement an interface and you are sure the arguments are writtten with the correct signature.

2a. The OP wrote "multiple classes of different names that use that class"
not "multiple variations of a base class."

True it isn't exactly polymorphism but as VB can not inherit from several baseclasses this is a the way to still use multiple signatures for an object.