-
Feb 25th, 2015, 03:25 AM
#1
Thread Starter
Frenzied Member
Which event raised the event procedure?
Where a procedure handles more that one event, how can the event that raised the procedure be determined?
-
Feb 25th, 2015, 04:01 AM
#2
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.
The best argument against democracy is a five minute conversation with the average voter - Winston Churchill
Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd
-
Feb 25th, 2015, 04:03 AM
#3
Thread Starter
Frenzied Member
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.
-
Feb 25th, 2015, 04:37 AM
#4
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.
The best argument against democracy is a five minute conversation with the average voter - Winston Churchill
Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd
-
Feb 25th, 2015, 07:18 AM
#5
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."
-
Feb 25th, 2015, 11:35 AM
#6
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
-
Feb 25th, 2015, 11:21 PM
#7
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
-
Feb 26th, 2015, 05:27 AM
#8
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.
The best argument against democracy is a five minute conversation with the average voter - Winston Churchill
Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd
-
Feb 26th, 2015, 08:06 AM
#9
Re: Which event raised the event procedure?
Originally Posted by FunkyDexter
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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|