The 'event' keyword is some magic that's worth describing separately. A field marked as 'event' will allow only += and -= operations from any location outside the class (i.e. calling it or otherwise taking its value will fail as if the field is declared private). I'm not sure if operations like directly assigning it are allowed inside the class. You can also declare explicit 'add' and 'remove' handlers (much like 'get' and 'set' for properties) if you want to.

There are two things to explain with "new myEventHandler(dealWithString)":

1. You can actually just write "dealWithString", and the "new myEventHandler(...)" part will be generated for you.

2. Either way, you are capturing the 'this' pointer at the time (it is part of the delegate instance you just made), so yes, it will be called on your main class instance later on.

The next two things you might find interesting:

Lambda functions are like inline delegates, but these are capable of capturing local variables in addition to 'this'. So you can write something like:
myClassInstance.onGetString += (source, e) => { ...code goes here... };
(You can write explicit parameter types too if you want to.) Be aware that if you do this, the relevant locals get compiled as references into a temporary object instantiated each time their scope is entered (this is true both inside and outside the lambda). [EDIT: Also, beware of the lambda foreach bug - the 'foreach' iterator variable is instantiated once, so if you use it in a lambda inside the loop, then all instances of the lambda ultimately see the last value it took on during the iteration. However, they fixed this in some new version of C# by changing the way 'foreach' is compiled.]

If you choose not to use 'event', then the code will still work but through a different mechanism. The operators '+' and '-' are supported for delegates, but they create new instances, just as with strings. So, if you write "x += y", then it compiles into a read operation on 'x', a combine operation which makes a new delegate object without disturbing the old ones, and then an assignment operation (just as with strings). A delegate contains a list of methods, which is used if you later use the '-' or '-=' operators. Calling a delegate entails calling the methods in sequence. Perhaps an event field is implemented this way too, but in a more wrapped fashion (the class does it itself), I'm not sure - and of course you have the option to override this, which you don't if you don't use the 'event' keyword.

Hope that helps

Yep. That part of the operation is exactly like a function pointer call

Or if you want a C++ parallel, then a functor - one which wraps the 'this' and any locals, same way a C++ functor (callable object) can.

The usual pattern is as follows (note, C# usually uses upper-camel-case, not lower-camel-case as a style rule):

Output:

Wow, we've counted to 9001!
Wow, we've counted to 9002!
Wow, we've counted to 9003!
Wow, we've counted to 9004!
Wow, we've counted to 9005!
Wow, we've counted to 9006!
Wow, we've counted to 9007!
Wow, we've counted to 9008!
Wow, we've counted to 9009!
Wow, we've counted to 9010!

Ah, that's cool. I knew they were introducing a null-safe dot operator. Either "?." or ".?". I forget. I haven't gotten to use those features yet because we weren't getting Visual Studio upgrades... Though now I think that we're all running the free community edition so we probably could take advantage of those features now. C# events happen to come up relatively rarely in my professional work because it's almost all Web-based.

1) The OnOver9000 overload is an optional convenience. If it so happens that the event can occur in many places. Putting this into a method saves the redundant task of constructing the object with the integer parameter.

On the other hand, having both makes it trivial and efficient to pass an existing Over9000EventArgs instance as the argument rather than forcing yourself to construct a new one just because your API is limited. The int-overload's job is just constructing the args object and passing it on to the other one that actually does the work.

2) I am using delegates, but it's being hidden with syntactic-sugar and API-sugar. The standard EventHandler<T> type is a delegate. This is a generic definition for the shape of an event. This saves you the redundant job of defining a delegate type for each event.

EventHandler<X>
// is the same as
XEventHandler
// where
delegate void EventHandler<T>(object sender, T args);
delegate void XEventHandler(object sender, X args);

There is an additional version too for when your event takes no real arguments:

delegate void EventHandler(object sender, EventArgs args);

It just accepts the stateless base class to fit the event interface pattern.

3) There are two OnOver9000 methods. One accepts an int, the other accepts the derived EventArgs object. The int override constructs the derived object from the int parameter and passes that along to the object override. The object override actually invokes the delegate with the EventArgs parameter. It's just a bit of forward-thinking code-reuse. Completely optional and not at all necessary here.