
Changing control name of button doesn't change event name to be the same
This isn't really a bug. There are two names used in an event:
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnTest.Click
The first name, following the word "Sub," ("Button2 in this code example)
isn't used the same way in VB.Net as it was in earlier versions of VB. It is
merely the name of a Sub (not the name of any control, necessarily). The
second use of the name (following the word "Handles" is the key: it does
tell VB.NET which control this event is for. So you can change this line by
giving it a new Sub name, and it will work just the same:
Private Sub Maximus_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnTest.Click
So you can freely change the name of the Sub to pretty much whatever pleases
you--just as you can name variables or procedures pretty much whatever you
want. It's the object reference at the end ("btnTest.Click") that defines
which control is involved.
You can even combine several controls events into a single procedure, like
this:
Private Sub Maxiumus_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnTest.Click, btnOtherOne.Click, btnCancel.Click
Then in the code, you identify which button was clicked by using the
"Sender" argument, like this:
Private Sub cmd_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles cmdOK.Click, cmdApply.Click, cmdCancel.Click
Select Case sender.Name
Case "cmdOK"
'Insert Code Here to deal with their clicking the OK button
Case "cmdApply"
'Insert Code Here for Apply button clicking
Case "cmdCancel"
'Insert Code Here for Cancel button clicks
End Select
End Sub
Going even further into outer space, consider the fact that a single event
"Sub" could even handle different kinds of controls, not just a group of
buttons, for example, but some labels, a TextBox or whatever.
To accomplish what control arrays used to do in earlier versions of VB, you
must now in VB.NET instantiate controls (as objects) during runtime, and
then let them share events. However, instead of using index numbers to
determine what you want a control to do (when it triggers an event) as was
the case with control arrays, you must now check an object reference (each
instantiated control should be given its own, unique name by the
programmer--this doesn't happen automatically). You are also responsible for
creating events for runtime-generated controls.
Quote:
> When changing the name of a button control the original name of the
events
> remains the same and continues to function (unlike vb6). This makes it
> extremely difficult to determine what event is being fired if you can't
> match the event name with the control name.
> Steps to reproduce:
> 1) Create New Window Application
> 2) Double click on button in toolbar (creates button1)
> 3) Double click on button to create button1_click event
> 4) Add some code to section (i.e. Call MsgBox("Prompt",
> MsgBoxStyle.Critical, "Title"))
> 5) Go back to form design and change name of button to btnTest
> 6) Double-click on button and it takes you to the button1_click event (the
> event is still synced with the button and the msgbox code still works)
> 7) Change the name of the click event the event is still synced with the
> button
> 8) However if you get rid of the code and double click on the button you
get
> an expected btnTest_Click event
> Questions:
> 1) Is this a bug?
> 2) If it is not a bug, how can a developer tell what event is hooked up to
> what control?
> 3) How do you cut and paste code unless the control names match the name
of
> the control and you don't have a handler for it already?
> 3) Couldn't it function like vb6 where you change the name and the event
> code is now dead/detached?
> Just seems confusing ...
> Thanks,
> Mark Brown
> Devsolution
> P.S. This also happens with a textbox control and is probably consistent
> with all controls.