Codings not changed when a control is renamed in VS2005.

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm new to Visual Studio 2005. I'm creating a windows application using
Visual Basic. After I added a control to a form and added some codings to
the control, I want to rename the control. However, I notice that after I
rename the control, the codings inside it are still using the old name. Is
there a setting that I can set to replace the old name with the new name
automatically (for the entire form or all coding within the same project)
when I rename a control? Also, after I deleted a control from a form, I can
still see the coding of the deleted control. Is there a setting to remove
those
codings automatically when the control is deleted?
 
In Visual Studio, open the options form through Tools / Options. On the left
side, select the Windows Forms Designer / General tree branch. On the right
side, make sure that "EnableRefactoringOnRename" is set to True. It will
slow down your IDE when renaming, but it should update all references to
a control name.
 
Hi Patrick,

It is already true. It does change any reference to the object. However,
it does not change the subroutine name. For example, I have added a button
to a form. The button is default with the name Button1. I clicked the
button so the Private Sub Button1_Click coding is created automatically. Then
I added some codings to the subroutine. When I rename the button from
Button1 to YesButton, I want the subroutine Button1_Click renamed to
YesButton_Click. Actually, I have not tried yet whether that Button1_Click
subroutine will still run or not when I click on the YesButton control. If
another person looks at the coding, how can he/she knows Button1_Click is for
the YesButton?

Peter
 
Hi Patrick,

It is already true. It does change any reference to the object. However,
it does not change the subroutine name. For example, I have added a button
to a form. The button is default with the name Button1. I clicked the
button so the Private Sub Button1_Click coding is created automatically. Then
I added some codings to the subroutine. When I rename the button from
Button1 to YesButton, I want the subroutine Button1_Click renamed to
YesButton_Click. Actually, I have not tried yet whether that Button1_Click
subroutine will still run or not when I click on the YesButton control. If
another person looks at the coding, how can he/she knows Button1_Click is for
the YesButton?

Peter
Click to expand...

Because after the method declaration, you should see a Handles clause
which tells which button the method handles.

It doesn't really make sense for the method to be renamed anyway,
because the same method might be used for several different buttons.

Consider this:

Suppose you had 3 buttons on the form: Button1, Button2, and Button3

Now suppose you had one click method for all three buttons:

'This method handles the click event for all 3 buttons.
Private Sub ButtonClick(...) Handles Button1.Click, Button2.Click,
Button3.Click
End Sub

If you then renamed Button2 to YesButton, how would the IDE know what
to rename the click method to? And if it somehow renamed the method
to 'Button2Click', then it would not make sense for Buttons 1 and 3
which are serviced by the same sub.

The name of the Click sub is irrelavant to the event.

Chris
 
That's true, because in .NET, subroutine names for event are not considered
important. You no longer have to name your events "Button1_Click". Instead
you can name them "BlueSuedeShoes" and it will work just fine.

Private Sub BlueSuedeShoes(...) Handles Button1.Click
End Sub

The Handles clause is what is important. And since the Handles clause can
be followed by multiple comma-separated event names (such as "Button1.Click,
Button2.Click, Button3.Click"), the routine name will not always match an
event signature anyway. Visual Studio doesn't want to mess with whatever
meaningful names you gave to the event handler, so it leaves it alone.
 
Hi Chris,

I understand the scenario you're talking about. I didn't notice the Handle
part. I guess the Handle part is actually indicating which control
events/methods are binded to the subroutine.

So, when I delete a control, VS just removes the handle of the control from
the subroutine and leave the subroutine there. If there is the case and I
have many controls on a from and then later on I delete many of them, the
form will contain many routines which have no handle part. Is there a way to
delete those automatically?

Peter



Peter
 
Peter said:
Hi Chris,

I understand the scenario you're talking about. I didn't notice the
Handle
part. I guess the Handle part is actually indicating which control
events/methods are binded to the subroutine.

So, when I delete a control, VS just removes the handle of the control
from
the subroutine and leave the subroutine there. If there is the case and
I
have many controls on a from and then later on I delete many of them, the
form will contain many routines which have no handle part. Is there a way
to
delete those automatically?

Peter



Peter
Click to expand...

Remember that you can use the same sub to handle events from many controls.
Removing the code can not be done since the IDE has no idea what you are
trying to accomplish when you delete a control. There are situations where
you can delete a button from one place on the form and then add it somewhere
else. If you were to have the handler code automatically deleted I would
think that would be a worse situation.

LS
 
Hi Lloyd,

I agree with you. May be the right-click menu should include a special
delete function to delete both control and related codings?


Peter
 
Back
Top