is it possible to tel wich control raised the event Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click, Button2.Click
' Add event-handler code here.
End Sub
For example i want to disable button wich raised this event
How can i do that
is it possible to tel wich control raised the event?
Attila Fogel
But the routine doesn't 'know' that - that's why you have to check.
Lynette2
If you used a subroutine as a handler for an event for many different types of control then it is error prone and more fool you if you did not write the code to sift out the sender using say IF sender Is Button...ElseIf sender Is TextBox...
However, where the handler is only handling for a given control type and only the controls you have listed it to handle are of that type where is the "prone" as the control type and which controls it handles is a given. If any other control fired off the event then you are already in dirty water and something is seriously wrong elsewhere.
Besides it is extremely useful to be able to do this, an addition is that you can also get the title string with the .text attribute. As an example I have written an EPOS style application to run our till and interface with our website, currently three seperate databases soon to be one thanks to VS. Throughout there is the need to get a numeric value from the user for quantity etc., to do this I implement a class that displays large number buttons each with the number of its value on it as its title, the handler builds a string of the value as each button is pressed returning on OK/Cancel buttons. Being able to access the .text means I have a very short single handler for the value buttons.
Private Sub B_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click, Button9.Click, Button8.Click, Button7.Click, Button6.Click, Button5.Click, Button4.Click, Button3.Click, Button2.Click, Button0.Click, Button00.Click
tbEnteredValue.Text = tbEnteredValue.Text + sender.text
tbEnteredValue.Focus()
End Sub
The alternative is to write eleven handlers, that all do the same thing ...so you would have eleven times:
Private Sub ButtonX_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ButtonX.Click
tbEnteredValue.Text = tbEnteredValue.Text + "x"
tbEnteredValue.Focus()
End Sub
Where x would be a constant string of 1, 2, 3, 4, 5, etc. Where is the method I use prone
As a follow on for the question you can just say sender.enabled = false.
Michael.
Gurpreet Singh Gill
But in the example you sent both controls used to fire the event were buttons. If they were different control types then you need to ensure that you cast to the correct type of control.
But either way the sender parameter is what you need to look at.
Whoisit
You can also say :
if sender.name = "button2" then
...
end if
Undocumented and it does not appear in the intellisense popup thingy but it works.
X4U
Might I say that your method of forcing sender to BE a button is not safe if the sender is not a button...unpredictable results just as error prone, only works because sender IS a button.
Michael.
macroplay
Sure but if you wrote the code, and you can see that the event is only being used for a specific type then you shouldnt need to check (theres no problem actually doing something).
Taking a step back in time, if you look at control arrays - do you check to see that the item is of type x when you execute something in there - no.
This is similar in that if you hook up the event to a number of different buttons (all are the same control type) then you can cast sender to that type.
The problem comes about as a result of event handlers allowing you to hookup different controls events to the same method. In which case - yes you would need to check the type before casting - as it could be one of a number of different controls.
Nishakant
Rememer that the above code could cause an error, since the sender is not necessarily a Button object: if you try to cast the sender as a button and it cannot be cast, an exception will be thrown.
You would be better served by checking that the sender is what you are expecting by checking the sender type, or performing a TryCast(). Neglecting such tests are a common cause for program crashes.
SunilN
Does it I think you will find that's even worse, and extremely error prone. It only works under these conditions:
The objective is to ensure that the routine works under all conditions.
Juco
Sure, this is what sender is telling you.
Example Code
Public Class Form1
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click, Button1.Click
CType(sender, Button).Enabled = False
End Sub
End Class