As mentioned in the discussion of the Name property, a control's Name becomes
part of all the event procedure names of that control. For example, the control
named txtFirst would have event procedures named txtFirst_Change,
txtFirst_GotFocus, txtFirst_Click,
and so on.
If you change a control's
Name, you automatically create new event procedures.
If there is already code in the event procedures
that uses the old name, those procedures will
not be renamed and the code will become "orphaned."
The good news is that the old
event procedures are not destroyed outright.
However, if you want to get the old event procedures
back, you must either copy and paste the code
into the event procedures with the new names,
rename the old procedures, or rename the control
back to its previous name.
For example, if you add a
CommandButton named Command1 to a form, write
code in its Click event procedure, and then
change Command1's name to cmdOK, the event
procedure name does not change and would still
be named Command1_Click. Therefore, the procedure
would no longer be associated with the CommandButton.
CommandOK_Click would be the name of the current
Click event procedure, and obviously this event
procedure begins life with no code.
Conversely, if you happen to
write a general procedure and later rename a
control in such a way that one of its event
procedure names happens to match the name of
the existing general procedure, then that general
procedure becomes an event procedure for the
control.
For example, if you write
a general procedure whose declaration looks
like this:
Private Sub Bozo_Change()
and then later rename a TextBox control to "Bozo," VB associates the Bozo_Change
procedure with the TextBox named "Bozo."
