Hi AndreB,
It is not correct I'm afraid.
Events are two or three methods (accessors) add, remove and invoke. Some
languages use invoke (C++), others don't (C#, VB) Just like properties are
declaration of set and get accessors. In this way events are not objects and
they cannot live in collections.
You might be confused by the work c# compilers does behind the scene to make
events look like objects.
When you declare an event using the line
public event EventHandler MyEvent;
What the compiler does is:
1. Declare one private member of delegate type
private EventHandler MyEvent
2. Declare two accessor methods with default implementation. They have the
visiblility of the access modifier you used when declared the event
void add_MyEvent(EventHandler h)
{
.....
}
void remove_MyEvent(EventHandler h)
{
.....
}
3. Emits the necessary metadata for the event.
So, now if you write the event in its other form, which is more close to
what events actually looks like from the CLR's point of view
public EventHandler MyEvent
{
add
{
....
}
remove
{
....
}
}
You can see that this cannot be put into a collection.
You can create a collection of delegates used by the events, but cannot
create collection of events.
Just for information. The classes in the WindowsForms frame work exposes a
big number of events. Applications uses a very few of them. It will be waste
of memory if they keep delegate variable member for each event. That's why
instead of having those variables they have a collection of delegates and
add and remove accessors for each event. At the begining the collection is
empty. Delegates are created at the moment the first time an event is
hooked.
So, to summarize. You cannot have collection of events, but you can have
collection of delegates.
