> What do you mean the "default implementation"? and the "keep a reference
> to
> the current delegate value in a private field with the same name as the
> event"
See Jon Skeet's article: http://www.yoda.arachsys.com/csharp/events.html
Or, for that matter, the MSDN discussion on events. You might start here:
http://msdn2.microsoft.com/en-us/library/edzehd2t.aspx
This page discusses more specifically what happens when you declare an
event:
http://msdn2.microsoft.com/en-us/library/wkzf914z.aspx
> Also, where is the standard place to put the delegate declaration? In my
> example, I have it outside of my classes, but I have seen it used inside
> of
> a class and called by a.delegate().
I think that depends on how the delegate is used. I think that a nested
type makes sense when it is some way specifically part of the containing
type. For classes, this often means you want to be able to access members
of the containing class, but that's not an issue for delegate types. So
it would be more an issue that the delegate type only makes sense in the
context of the containing class.
If that's not the case, I'd declare the delegate type outside the class.
That assumes, of course, that there's some point in declaring the delegate
type at all. For example, if you are declaring your own EventArgs-derived
class for the event, then you'll want a matching delegate type that uses
that type. But for basic events, often you can just use the .NET
EventHandler type, and sometimes for more specific events you can still
share an existing EventArgs-derived class and thus the associated delegate
type.
And of course, there's no requirement that you use the EventArgs pattern
for events. Even though you should always consider using that pattern
because of its consistency with the rest of .NET, you may find that your
event delegate type matches some existing delegate type from .NET (if
nothing else, a general-purpose delegate type for the event can be
declared using the generic Action<> or Func<> types).
Pete