What is the difference between event and multicast delegate

[AliRezaGoogle]

Hi,
I have a conceptual question on Events and Multicast Delegates. Let me
explain:

As we know an event is a multicast delegate. What we declare as an
event is inherently a multicast delegate. I really do not undrestand
what additional features the "event" keyword adds to multicast
delegate. The only thing that I see as an additional feature is a
"Thunder Icon" near event name in VS IDE when intellisense works.

Can anybody clarify this matter for me?

 

[Cowboy \(Gregory A. Beamer\)]

I believe event is derived from multicast delegate and not he other way
around. If I understand it correct, event is a C# keyword that shortcuts the
creation of a mutlicast delegate (or perhaps it would be better to say "a
particular type of multicast delegate"). It is not a superclass for
multicast delegate.

The thunder icon is a feature of the IDE and does not affect the underlying
classes. It is designed to make it easier for you to find your events.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************

 

[Jon Skeet [C# MVP]]

I have a conceptual question on Events and Multicast Delegates. Let me
explain:

As we know an event is a multicast delegate.

No it's not. It's a pair of methods - add and remove, or subscribe and
unsubscribe.

See http://pobox.com/~skeet/csharp/events.html for a great deal more
info on this.

 

[Marc Gravell]

As we know an event is a multicast delegate.

No; an event is defined as a set of accessor methods that encapsulate
a delegate in the same way as a property encapsulates a regular field.
Where a property defined "get" and "set", an event defines "add" and
"remove". That is all an event is. This provides the same abstraction
as properties, and formalizes the contract: you can subscribe and
unsubscribe, but you don't have direct control of the delegate.

In particular, this prevents 2 unwanted scenarios:

a: obj.SomeEvent = SomeHandler;
(damn, what happened to the other subscribers?)

b: obj.SomeEvent(...)
(only "obj" should be invoking the event - not external callers)

It also allows for abstraction in terms of how the delegate is stored.
A good example of this is windows forms; they have lots of events,
which most of the time aren't subscribed. Having a delegate field per
event would be expensive, so instead an EventHandlerList is used to
store sparse subscriptions efficiently. You could also (for example)
do other processing when adding/removing subscribers: check access,
facade to another property, lazy loading, etc.

Marc

 

[AliRezaGoogle]

Thanks a lot John. I followed your link and the article clarified
everything for me. Many thanks man.

 

[AliRezaGoogle]

Thanks a lot Marc. You are right in this point. Many thanks for your
help.