First, I think it's great that you are diligently studying all the possible forms of creating EventHandlers, and "wiring them up" to various Control Events.
For simple uses of EventHandlers, I see lots of benefits from letting Visual Studio create stubs for the programmer via double-clicking on the Control, or selecting an Event in the Property Browser for a Control. This is a "convenience" functionality that increases your productivity, and encapsulates simple logical relations so you can focus on your "larger scale" tasks at hand.
There are no performance penalties for making use of this built-in functionality, and, if you are obsessive-compulsive, you may receive a bonus of something new to worry about, if the syntax bothers you :)
The "organic" reasons for creating your own EventHandlers in code (using Lambda expressions, anonymous methods) arise when you are doing more complex things. Obviously, if you define your own Events, you have to define your own EventHandlers to use those Events, but, let's consider some other cases in which you'd want to define your own EventHandlers:
1. When you want to directly manipulate the fact that a .NET Event is a multi-cast delegate that maintains a queue of possible EventHandlers all of which will be executed. By "manipulate" I mean remove an existing EventHandler, add an EventHandler, restore a previously removed EventHandler, etc.
2. as in #1, but with the stipulation that you want to directly manipulate the
order in which EventHandlers in the Event's internal queue are executed.
3. in complex control situations where you might want to store EventHandlers. For example, imagine a Dictionary<TreeNode, CustomEvent> where you might want to execute different code based on a TreeNode. Or, imagine a "state machine" type of UI, where for each "state," you'd want to assign different EventHandlers to certain Controls that are present in the UI for each state.
An example of storing Delegates as Values in a Dictionary can be found in my article on DevX: [
^]. You could store EventHandlers in exactly the same way.
Scenario #2 is one I am dealing with right now in a Project I am working on, and I have "solved" it by creating a static Property of Type Action in a static Class: under different circumstances different EventHandlers are assigned to that Property by various Forms, and the sequence of execution of the EventHandlers in response to a certain UI Event is re-structured. Sounds more exotic than it is.
This type of solution allows me to execute an EventHandler defined within various external objects (Forms) with no specific "tight coupling" between the static Class and the Forms, and, of course, since the EventHandler definition is "inside" a Form, it has access to all of the Form's private/public Fields, Methods, etc., while the static Class does not.