[RESOLVED] The difference. RaisedEvent's RaisedDelegates

would some one mind explaining the difference in what i have shown here.

vb Code:

Public Class MainForm
 
    Private Delegate Sub RaiseSomeEventDelegate(ByVal text As String)
    Private Event SomeEventArghs As RaiseSomeEventDelegate
 
    Private Sub EventDelegate()
        ' Is this event handler now handled on a new thread?
        RaiseEvent SomeEventArghs("Value")
    End Sub
 
    Private Event SomeEventhandler As EventHandler
 
    Private Sub SomeEventMethod()
        ' Should Me always be passed or is it acceptable
        ' to pass any value?
        RaiseEvent SomeEventhandler(Me, EventArgs.Empty)
        RaiseEvent SomeEventhandler("pass a value", EventArgs.Empty)
    End Sub
 
    ' Is this acceptable or should this be a new delegate?
    Private Event CustomEvent(ByVal value As String)
 
End Class

Lastly do you guys/gals name your events/delegates using that as a last word?

SomeEventAsEventArghs
SomeDelegateAsDelegate

thanks :)

After searching the forum i stumbled upon this article by JMC http://jmcilhinney.blogspot.co.uk/ It has pretty much answered all my questions so think it's best i provide the Link. How ever i am left with one question.

JMC said it's more appropriate to use the EventHandler(TEventArgs) delegate. The events i need to handle only pass one or two values of new information. So writing a separate class seems silly. Would it be better suited to use a custom delegate to raise as in my first example or just give the event a custom signature as in my last example?

Like a lot of things... it depends...

if you don't have to pass any custom data... then simply use the default SystemEventArgs class... if you DO need to pass additional data, then best practice is to create a custom class that inherits from SystemEventArgs, add your additional properties to it... then use that class to pass the data over.

-tg

Quote:

---

Is this event handler now handled on a new thread?

---

No it isn't. Whatever thread the method that raises the event is being executed on is the same thread that the event handler is executed on.

Quote:

---

Should Me always be passed or is it acceptable to pass any value?

---

Objects always raise their own events and the 'sender' parameter is a reference to the object that raised the event so that first argument should always be Me.

Quote:

---

Is this acceptable or should this be a new delegate?

---

That will work but that is not the only criterion to consider when deciding whether to do something. There are lots of things that will work but should never be done. It is good practice to always use the (sender As Object, e As EventArgs) pattern for events. Defining your own class that inherits EventArgs will take you about 2 minutes so that's a very small price to pay for conforming to good practice that will make following your code easier for you and others. If something looks familiar then it's easy to follow and easy to extend if required.

EDIT: You could even write a code snippet for a class that inherits EventArgs and that would make it even quicker to define such a class.

Quote:

---

Lastly do you guys/gals name your events/delegates using that as a last word?

---

The event itself should always have a name that describes what the event is for, e.g. SomethingHappened. If the event requires custom data then you should define a class that inherits EventArgs. If that class is for that one event only then it should be named after the event and its base class, e.g. SomethingHappenedEventArgs. If the same class will be used for multiple events then it should have a name that either describes that group of events or the data it contains, whichever is more appropriate under the circumstances. With the EventHandler(Of TEventArgs) delegate there is no longer any need to define your own custom delegates for events but, if you were going to, they should be named after the event they will be used to handle, e.g. SomethingHappenedEventHandler.

Before i attempt to write this i just want to provide you with a little bit more information. Take IRC Raw numeric s. An irc client needs to handle all these. When a user joins a channel all i need to do is pass the channel and name. How ever there can be different factors.

What if it is me joining the channel? In this case i raise two events. First is a meJoinedEvent and the other is a UpdateToolBar event.(Enables toolbar buttons when in a channel) These are both Public Event SomeEvent As EventHandler

Neither of these events pass any information, only a notification i have joined. Simple as that. Would these stay as is other then over riding the event so it is only ever called in one place?

If it's not me i raise Three more events.

1) The output response i need to send to the UI so i users can see a new join.
2) Update the nicklist
3) Update the maintitle bar (Contains user count)

These Three carry information. Previously i would use it's own custom delegate. Would each of these require it's own class or would i compile them into one?

Think i need a fresh head in the morning before i write this :D

I think the first thing you need to consider is that an event is supposed to tell you what happened, not what you are supposed to do about it. It sounds to me like only one thing is happening, i.e. a user joins a channel, so it sounds like there should only be one event being raised. If you have to take multiple actions based on that event then that's fine but that's not any concern of the event. For instance, that UpdateToolBar event doesn't sound like it makes sense. It sounds like you should be raising a UserJoinedChannel event and then, in the handler for that event, calling an UpdateToolBar method. One is a notification that something happened and one is an action taken because of what happened.

Of that seems fair enough. But is it ok to handle that event in multiple places? For example the output message class does not need to know any thing other then the message to output. The toolbar is on another MDI form & does not even know the output class exists. What if i wanted to kick this user on join. The output class nor MDI parent needs to know any thing about this. Or should i have one event handler that handles each action & passes the information across.

I don't know everything about your app so maybe more than one event is appropriate but I'm fairly sure that you don't need all the events you were suggesting. Like I said, an event should indicate what happened, not what you should do about it. That doesn't necessarily mean that one action can't lead to multiple events. Consider when you type into a TextBox. When you depress a key the KeyDown event is raised. When you then release that key, the KeyPress, KeyUp and TextChanged events will all be raised. The reason for the multiple events is that they all indicate slightly different things and there are also situations where on or other of those events will be raised but the others won't.

So, you need to determine whether just one or multiple events are appropriate. If the events actually indicate that different things happened then by all means use multiple events. Two events that indicate the same thing but provide different data are not appropriate. Just because an event provides data doesn;t mean that the handler is obliged to make use of it. Also, to answer your question, handling the same event in multiple places is quite appropriate.

Sorry for the late reply. It's for an IRC client so there are loads of events going on often. Most events will be passing data for example a OnJoinedEvent would pass nick, address, #channel

vb Code:

Public Class UserJoinedChannelEventArgs
    Inherits EventArgs
 
    Private ReadOnly m_nick As String
    Private ReadOnly m_channel As String
 
    Public ReadOnly Property Nick() As String
        Get
            Return Me.m_nick
        End Get
    End Property
 
    Public ReadOnly Property Channel() As String
        Get
            Return Me.m_channel
        End Get
    End Property
 
    Public Sub New(ByVal nick As String, ByVal channel As String)
        Me.m_nick = nick
        Me.m_channel = channel
    End Sub
End Class

vb Code:

Public Class SomeIrcClass
 
    Public Event OnUserJoining As EventHandler(Of UserJoinedChannelEventArgs)
 
    Protected Overridable Sub OnUserJoined(ByVal e As UserJoinedChannelEventArgs)
        RaiseEvent OnUserJoining(Me, e)
    End Sub
 
    Private Sub SomeEvent()
        ' read the stream
        '
        ' user joined
        Me.OnUserJoined(New UserJoinedChannelEventArgs("nick", "#channel"))
    End Sub
End Class

This look about right? So each event should have it's own class? Looks like i have a lot of writing todo :D

Looks almost right but there are a couple of issues. First, your SomeEvent method has nothing to do with events. It's not an event and it's not even an event handler. It's just a method, so it would be SomeMethod. I know that neither of those are names that you'd use in a real app but it's important to keep straight what is what in your head and the name SomeEvent suggests that you are thinking that that method has more to do with events than it does.

Secondly, you have a method named OnUserJoined raising an event named OnUserJoining. That's bad, misleading naming. If you haven't already then you should read my blog post on custom events to learn how to name them properly. Firstly, an event name never begins with "On". You name the event based on what it represents and then you name the method raises it the same with the "On" prefix. So either your event should be UserJoining and your method should be OnUserJoining or your event should be UserJoined and your method should be OnUserJoined. Which one should it be? As my blog says, UserJoined would be raised after a user joins and UserJoining would be raised before a user joins.

I completely agree with the naming. I was quickly writing it together. The names i wrote are not the ones i would choose. I have read your blog. Really well written out. So forgetting the names every thing is ok?

I once viewed a project of yours message client-server and you used a separate class called delegates. How come events where not handled as your blog demonstrates? Or is it simply this is the new preferred way.

Thanks for all your help :)

Thanks for all the help & to any one else i suggest you keep an eye on Johns blog.