The benefit of events??

Hi,

I am trying to determine the best use for custom events.

Here is mytest code. (I know that the arguments are inappropriate for event handlers ... but this is just a test.) The code simply updates a Label control on the webform:

Namespace test
 Public Class events
 Inherits System.Web.UI.Page
 Protected lblMessage As System.Web.UI.WebControls.Label
 Protected Delegate Sub EventHandler( ByRef comment As String )
 Protected Event Event1 As EventHandler
 Protected Sub Page_Init( ByVal sender As System.Object, ByVal eArgs As System.EventArgs ) Handles MyBase.Init
 AddHandler Me.Event1, AddressOf Me.Event1Handler
 AddHandler Me.Event1, AddressOf Me.Event2Handler
 End Sub
 Protected Sub Page_Load( ByVal sender As System.Object, ByVal eArgs As System.EventArgs ) Handles MyBase.Load
 If Not Page.IsPostBack Then
 Dim toSay As String = "raised as event"
 RaiseEvent Event1( toSay )
 RaiseEvent Event1( toSay )
 Event1Handler( "called as method" )
 End If
 End Sub
 Private Sub Event1Handler( ByRef comment As String )
 lblMessage.Text &= "Event1Handler: " & comment
 comment &= ", changed by Event1Handler"
 End Sub
 Private Sub Event2Handler( ByRef comment As String )
 lblMessage.Text &= "Event2Handler: " & comment
 comment &= ", changed by Event2Handler"
 End Sub
 End Class
End Namespace

In terms of functionality, there doesn't seem to be any difference between raising an event [RaiseEvent Event1( "raised as event" )] and "calling" the event handler directly [Event1Handler( "called as method" )].

In my test, they did exactly the same thing. I can see only two benefits to using events.

First, I can dynamically attach one or more methods to an event. This helps in implementing certain design patterns.

Second, a raised event need not be handled at all. Whereas calling a missing method generates an exception, raising a custom event with no handler is okay.

Am I missing the importance of events?Well,

in your example Event1Handler is private method (it is event handler after all).

Generally events should have corresponding protected method <On>EventName which is used to raise the event by calling it.

For example you have :

Protected Event Event1 As EventHandler

which would have corresponding method:

Protected Sub OnEvent1(comment As String)
 RaiseEvent Event1(comment1)
End Sub

which would provide a way for inherited classes to raise the event by calling the inherited method.

OnEvent1("Something")

So it is the inheritance thing in picture as well.

And usually event should always provide the sender of the event (object that raises the event) so that event's consumer would have straight access to the object that is raising the event (another alternative is of course just give enough event arguments)

C# provides a way to check if event has listeners attached so that event wouldn't be raised if there are no listeners (to save some horsepower ;-) ). VB doesn't currently have this feature.