Results 1 to 9 of 9

Thread: Which event raised the event procedure?

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Jan 2001
    Posts
    1,345

    Which event raised the event procedure?

    Where a procedure handles more that one event, how can the event that raised the procedure be determined?

  2. #2
    Super Moderator FunkyDexter's Avatar
    Join Date
    Apr 2005
    Location
    An obscure body in the SK system. The inhabitants call it Earth
    Posts
    7,612

    Re: Which event raised the event procedure?

    I don't think you can tell which event fired it. The sender parameter will tell you which control raised the event but if your sub is the handler several events for the same control with the same parm signature you wouldn't know which event was fired.

    My suggestion would be to use separate handlers for each event but have the handlers call on to your sub. The handlers could pass the event name in as a parameter so your sub could behave appropriately.
    You can depend upon the Americans to do the right thing. But only after they have exhausted every other possibility - Winston Churchill

    Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd

  3. #3

    Thread Starter
    Frenzied Member
    Join Date
    Jan 2001
    Posts
    1,345

    Re: Which event raised the event procedure?

    Thanks that sounds like a good suggestion. I just wanted to integrate into a single sub if possible.

  4. #4
    Super Moderator FunkyDexter's Avatar
    Join Date
    Apr 2005
    Location
    An obscure body in the SK system. The inhabitants call it Earth
    Posts
    7,612

    Re: Which event raised the event procedure?

    Well you'd have all your functionality in a single sub. The event handlers would be simple pass-through methods who's only responsibility would be to identify which event was being fired.
    You can depend upon the Americans to do the right thing. But only after they have exhausted every other possibility - Winston Churchill

    Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd

  5. #5
    PowerPoster SJWhiteley's Avatar
    Join Date
    Feb 2009
    Location
    South of the Mason-Dixon Line
    Posts
    2,256

    Re: Which event raised the event procedure?

    As already noted, the sender identifies the control which raised the event; this is how you perform the identification (it's the whole point of the sender).

    Of course, if (for example) you have multiple buttons with one handler, then the sender will be a button object and you can cast (or, rather, TryCast) it to a button. Each button object will/should have specific properties which uniquely identify it. the Tag property of controls allow you to store any object you like. So you could TryCast() to a button then TryCast() the Tag to your identifying object.
    "Ok, my response to that is pending a Google search" - Bucky Katt.
    "There are two types of people in the world: Those who can extrapolate from incomplete data sets." - Unk.
    "Before you can 'think outside the box' you need to understand where the box is."

  6. #6
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    35,238

    Re: Which event raised the event procedure?

    There is a rare case where you would be able to identify between different callers, but it's not a good idea. If the signature of the event handler had e As EventArgs as the second argument, then the handler could handle nearly any event, since most events will pass some object derived from EventArgs as the second argument. In that case, you may be able to differentiate the caller by examinging the type of the argument passed. This is a pretty bad idea, though, because it would mean making more work for the computer to do with the only benefit being slightly neater code.

    I much prefer the idea of putting all the code in one sub, then having event handlers for each relevant event, and letting the event handlers call the sub.
    My usual boring signature: Nothing

  7. #7
    PowerPoster
    Join Date
    Oct 2010
    Posts
    2,141

    Re: Which event raised the event procedure?

    For what its worth, you can use the StackTrace to get the calling method (OnSomething) using code similar to this.

    Code:
    Private Sub Label1_Handler(ByVal sender As System.Object, ByVal e As System.EventArgs) _
                Handles Label1.Click, Label1.MouseLeave, Label1.MouseDown, Label1.MouseEnter
       Dim st As New StackTrace
       Dim frames As StackFrame() = st.GetFrames
    
       If frames.Length > 0 Then
          Dim frameNumber As Int32
          Dim frame As StackFrame
          Dim meth As Reflection.MethodBase
          ' the 1st frame (Index = 0) would be this method
          Do
             frameNumber += 1
             frame = frames(frameNumber)
             meth = frame.GetMethod
             If meth.Name <> "Invoke" OrElse frameNumber = frames.GetUpperBound(0) Then
                Exit Do
             End If
          Loop
    
          TextBox1.AppendText(String.Format("Calling Method: {0}{1}", meth.Name, Environment.NewLine))
       End If
    End Sub

  8. #8
    Super Moderator FunkyDexter's Avatar
    Join Date
    Apr 2005
    Location
    An obscure body in the SK system. The inhabitants call it Earth
    Posts
    7,612

    Re: Which event raised the event procedure?

    The more I think about this the more I think we're probably kicking some bad design down the road.

    Why do you want to know which event fired the sub? The sub should have a single behaviour regardless of what's calling it. If the behaviour is substantially different then it should be a separate sub.

    Does your sub contain a big if/case statement that takes it down different paths depending on which event fired it? If so that's bad design and you should turn it on it's head. Instead of having a single routine that behaves differently for different events you should have separate subs for each event but they should call small subs which implement any common behaviour.
    You can depend upon the Americans to do the right thing. But only after they have exhausted every other possibility - Winston Churchill

    Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd

  9. #9
    PowerPoster SJWhiteley's Avatar
    Join Date
    Feb 2009
    Location
    South of the Mason-Dixon Line
    Posts
    2,256

    Re: Which event raised the event procedure?

    Quote Originally Posted by FunkyDexter View Post
    The more I think about this the more I think we're probably kicking some bad design down the road.

    ...
    I'd agree with this. If you have a handler method handling multiple events, then you want the same behavior regardless of the object which raises the event. If you want different behavior then have a different handler.

    Just because we can add multiple events to a single handler, doesn't mean we should.
    "Ok, my response to that is pending a Google search" - Bucky Katt.
    "There are two types of people in the world: Those who can extrapolate from incomplete data sets." - Unk.
    "Before you can 'think outside the box' you need to understand where the box is."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width