It sure seems like it would make for a confusing final project if I had event handler methods whose names would not match the corresping object to which they respond. I can see how it can all work that way, but wouldn't it likely confuse any future programmer who tried to use my code? It just seems like a poor practice.

I don't understand why the refactor feature couldn't deal with this matter. It just seems like another mass replace on all the code files would deal with it.

I just tried it, and now I have the original event handlers using the old object name, and then I added a new event handler method on the object I had refactored (renamed) and it used the new name. I don't like it.






>The eventhandler names are not renamed and should not be renamed because multiple objects can "link" to the same evenhandler.
>
>>I tried it, and it seemed to work, except that it did not rename the event handlers.
>>
>>I refactored from "mmDataGridView1" to "mmGridCustomers" and it did not hit the event handlers:
>>
>>
>>
>> private void mmDataGridView1_CellContentClick(object sender, DataGridViewCellEventArgs e)
>> {
>> string CustNo = this.mmGridCustomers.GetCurrentRowPK();
>>
>>
>> }
>>
>>>Don't do it in the property sheet. Find a reference to it in the code. Right-click on it and select Refactor.
>>>
>>>>On a Windows Forms, how can I rename a control (using the Properties window in the IDE) knowing that there may be many event handlers and other references to the old name in other places in my codes?
>>>>
>>>>If you rename it immediately after placing it, you're ok, but what if you have already coded against it and then decide to rename it how do you fix all the references? Will it do it automatically or do I have to find all the places that need to be changed? Where all should I look?