>>>>>>It will take me 10 years to refactor all places where I have code in the event method (e.g. cmdSave.click()) :)
>>>>>
>>>>>Start with the ones where you're calling that code from elsewhere. There should never be calls to event methods.
>>>>>
>>>>>Tamar
>>>>
>>>>Just to clarify, when you are saying "never be calls to event method", you mean never code like this?
>>>>

>>>>*-- Some procedure or a method calling the click of a button:
>>>>SomForm.cmdSomeButton.Click()
>>>>

>>>
>>>Yes, that's what I mean. If you find yourself writing code that calls Click or KeyPress or GotFocus or ..., that code belongs in a method that's called from the event and from whatever the other place is.
>>
>>Why do you say that, Tamar? The code is encapsulated in the .click() event. Why create a new custom method and call that method from .click() and the place where you would use someForm.cmdSomeButton.click()? Why not keep it in .click() and call it there?
>
>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 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.