Matt,

>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();
>>>
>>>
>>> }
>>>

If I need to do this I just rename the methods manually in the code but then you have to go to the propery sheet/ Events page and use the down arrow to reselect the methods you want connected. It is a pain but as someone else mentioned, you might have something like btnNumbers_Click as a method tied to a whole bunch of buttons. You would think however the IDE would be able to recognize whent the actual control name is used and change it as opposed to a generic name event like I mentioned. Anyway it is what it is.
Tim