>>>
>>>Because it breaks encapsulation. Other objects shouldn't have to know about that button and its Click method. If down the road, for some reason, I decide to replace the command button with some other control (maybe a link), I shouldn't have to go find code that's calling that button's methods. In general, it's better if no control references any other control directly, but everything is mediated through the form. (And, no, I'm not perfect about this.)
>>
>>
>>You'll have to do that anyway if there's code on the click() event that's calling a method. Copying one line, or all of them is still the same number of keystrokes: Ctrl+A, Ctrl+X, then go to the new object, Ctrl+V.
>
>I guess you didn't read what Tamar wrote. If other controls call method on the form, than changing button in any way will not affect them. There is nothing to copy paste in that case. If on other hand other controls reference button click event, than you'll have to find all of them and modify all of them if button is renamed, replaced, etc

I read what she wrote. I solidly disagree with her on this point. But, she's staying out of it and not offering solid reasons why it's a good idea apart from style preferences.

>>I don't see how it breaks encapsulation. I can see if you're designing a base class, or a class on top of a base class to be used by other things, but on that final presentation for the form ... I see no reason not to include code on the events. In fact, every team I've worked with has done it that way for literally 20+ years. We've never had a single coding issue arise because of it.
>
>I guess you got lucky

Yeah. For 20+ years running hundreds of apps with thousands of users, some of them 24/7/365 mission critical, and never once having an issue. Must be luck. :-)