Develop Reference

struggling in understanding terms in the Delegate world

I'm new to C#, I'm very confused with the terms used like 'listener', 'caller', 'callback', 'EventHandler', let's say we have the following code below:
public class Car
{
public delegate void CarEngineHandler();
public CarEngineHandler listOfHandlers;
public void Accelerate(int delta)
{
if (delta > 80)
listOfHandlers(); // not checking null for simplicity
}
}
class Program
{
static void Main(string[] args)
{
Car myCar = new Car();
myCar.listOfHandlers = new Car.CarEngineHandler(CallWhenExploded);
myCar.Accelerate(120);
}
static void CallWhenExploded()
{
Console.WriteLine("Sorry, this car is dead...");
}
}
so in this scenario:
Who is the caller?
Who is the listener? listen to what?
Who is the callback?
Who is the EventHandler?
and my answer is:
The caller is myCar
not sure
The callback is CallWhenExploded() static function
EventHandler is listOfHandlers
am I correct? I really don't know who is the listener and listen to what.

Hopefully you understand that an variable of type string is like a bucket that holds a string of characters, and you can look at them individually, pass them round as a collection etc. It's quite an easy thing to visualize, this variable being a container that stores data, because we store data all the time in the real world; pieces of paper in a box/file etc
Delegates are like variables for methods - and this is a much harder concept to understand, that we can pass a method round as though it were just like data, and we can get the computer to run the method.. but that's what a delegate is. When you declare a delegate, it's like when you declare your own class:
delegate void SomeMethod(); //specify a delegate
class Person{ //specify a class
string FirstName;
string LastName;
}
Just like when you make a class, you're giving yourself the ability to create an instance of that class, when you declare a delegate you're giving yourself the ability to create an instance of that delegate. Your class instance refers to data, like here the first and last name of the person. A delegate instance refers to a method rather than referring to data. You can make one class instance that refers to "John" and "Smith". You can make a delegate instance that refers to Method1(). You can make another class instance that refers to "Bill" "Jones". You can make another delegate instance that refers to Method2().
You can associate any method with your delegate instance, so long as the method has a signature that is equal to the delegate. That delegate above will accept a reference to any method that takes no parameters and returns void. If you've got one or more of these kind of methods you can attach them to an instance of the delegate, pass the delegate instance like a variable, and the thing you've passed the delegate to can call the methods without needing to know what the method name is or anything about it.
Why would we want to do this? One major use of delegates is in event handling. Microsoft created UI controls that are capable of doing things - buttons you can click on. You'll want your button to do something when it's clicked, but everyone in the world will want their button to do something different when it's clicked, so Microsoft can't write the code for that. They can however say that they will make a button that takes a delegate (a method passed like a variable) and the button promises to call the method when it is clicked. You supply the code that does what you want, as a delegate, to the button. Your method has to have a certain signature (arguments) because the button wants to pass your method some data that may be helpful to you; perhaps the location of the mouse when the clock occurred, or the number of times it was clicked. UI components have hundreds of different kinds of events, they all run on delegates
Another good example of delegates is in the old style of async programming when we had Begin/End pairs of methods, calling Begin would typically start a new thread off doing something and we would have to supply a method (our method) to it that, when Microsoft's Begin method had finished doing something it would call our method to let us know it was done. Typically then our code would call End, passing in some reference our method had been given, and we'd get the result. Sending a request to a server would take some time, for example, so we'd Begin it, go do some other things, and when the response was ready we would be notified by our delegate being called and we would process the result
So, get used to the notion that a delegate is just a way or referring to a method, you pass it around, what you pass it to can run it and provide data to it without having a clue what it does. In terminology it is also referred to as a callback - the thing that will be called when the foreign method is done with its work, though it's a fairly loose term - it might be used to refer to either your method that does the work, or the instance of a delegate pointing to your method, the thing that is passed in. Effectively they're equivalent dependi on the context of the conversation
A delegate itself is more like a collection/array - you can attach multiple methods to it and when the delegate is called they will all run, though not in any defined order. In your example you assigned just one to it but it could be multiple:
SomeMethod delegs = null;
delegs += new SomeMethod(MyMethod1);
delegs += new SomeMethod(MyMethod2);
Invoking that delegate will cause both MyMethod1 and MyMethod2 to be run, possibly in 2,1 order
Events are delegates too, but they're a slightly special case, touched on above with the button click handler. When a delegate is specified with the event keyword it can only be invoked inside the class that declared the delegate variable. UI controls use this to ensure that only they can run the delegate; you can't reach into a button and force run its clock handlers yourself because the delegate list that handles a click is declared as an event. If you want to programmatically cause a button to fire its event handler list you normally have to subclass it so your code becomes operationally "inside" the button code
Listener as a phrase is more often associated with events but it's reasonably synonymous with callback and eventhandler - when you add a listener to an event, you're saying that you're writing code that will handle the occurrence of the event, your code (as a delegate/event handler) that acts when the event occurs. It doesn't "listen" per se; it just hangs around and gets kicked into action when the thing raising the event invokes the list of delegates/eventhandlers associated with the event.
As an aside, because delegate instances represent a variable that points to a method, i.e. they point to an action, your naming of the instances should be a verb, not a noun. You called yours listOfHandlers but it would have been more helpful to your understanding to call the delegate instance after the event/action that is occurring. The use case you were applying was one of overrevving so perhaps you should name it CarEngineOverRevving. You could have another for when the temperature exceeds. If both these delegates has the same signature (you want people who will handle these events to do so via a method with no arguments) then you can reuse the same delegate for the different events:
public void delegate CarEngineProblemHandler();
public CarEngineProblemHandler CarEngineOverRevving = null;
public CarEngineProblemHandler CarEngineOverheating = null;
The delegate is your way of declaring what you want the methods provided to you, that you will call, to look like. The list of named problems is what you are declaring other people can provide some handling for. I could decide to not give you a handler for overrevving because I will never do it, but overheating might happen anyway so I'll certainly give you a handler/listener/delegate/callback to call of it ever happens

You should be able to answer those questions when you understand 'broadcaster/subscriber' pattern used by delegates. 'broadcaster' holds the delegate instance and decides when to call target methods in its 'invocation list'. These target methods are the 'subscribers' and they can decide when to stop or start 'listening' by calling '-=' or '+=' on broadcaster's delegate field.
public class Car
{
// This is the 'delegate type'
// ‘Delegate type’ is what is responsible for defining the method such as its signature
// which include return type and parameters
// In this ‘Delegate type’ named:'CarEngineHandler', the return type is 'void' and there are no parameters
public delegate void CarEngineHandler();
//this is the ‘Delegate instance’
//‘Delegate instance’ is responsible for holding the reference to the actual methods
//that adheres to the delegate type.
//Delegate instance can be used to then ‘invoke’ that method whenever needed.
public CarEngineHandler listOfHandlers;
public void Accelerate(int delta)
{
if (delta > 80)
//this is where you use the 'Delegate instance' to ‘invoke’ the methods
// You can also you use: listOfHandlers.Invoke();
// which is same as calling 'listOfHandlers();'
// When delegate instance is invoked, all its actions in its invocation list are executed in order
//In this example it will first dispaly: "Sorry, this car is dead..."
// then display: "Calling, emergency..."
listOfHandlers(); // not checking null for simplicity
}
}
class Program
{
static void Main(string[] args)
{
Car myCar = new Car();
//This is where you add to the 'delegate instance', the 'target method's' that matches delegate signature
//A 'delegate instance' can contain more than one action. This list of actions is called the “invocation list”.
//You can also add multiple methods to invocation list like this: myCar.listOfHandlers += CallWhenExploded;
myCar.listOfHandlers = new Car.CarEngineHandler(CallWhenExploded);
// For example you can add another target method like this:
myCar.listOfHandlers += CallEmergencyService;
// you get details about the 'target methods' attached to the “invocation list” like this:
var listOfTargets = myCar.listOfHandlers.GetInvocationList();
Console.WriteLine(listOfTargets[0].Method.Name);
myCar.Accelerate(120);
}
static void CallWhenExploded()
{
Console.WriteLine("Sorry, this car is dead...");
}
static void CallEmergencyService()
{
Console.WriteLine("Calling, emergency...");
}
}

Event vs EventHandler

I read a lot of materials but I still did not understand, can someone explain me, please?
What do I know:
Declare an event:
public event MyEvent myEvent;
Vs.
declare EventHandler:
public EventHandler MyEventHandler;
While EventHandler is a keyword in .NET:
public delegate void EventHandler (Send object, EventArgs e);
So, EventHandler is a delegate and not an event, since it is not used in the keyword 'event'?
And when should I use 'Event' and when 'EventHandler'?

Ah, the event vs. delegate question. I remember having that question as well...
So, suppose you're making a class called "Cat" and you want to let people know when your cat is hungry. You could do that in one of two ways: by exposing a delegate on the Cat class or by exposing an event.
You can think of a delegate as a pointer to a function (or method). So let's say there's a class called "Person" that has a method called FeedCat(Cat cat).
The delegate way
If your cat is exposing a delegate called HungryDelegate, the person can point the delegate to their FeedCat method, so that when the cat is hungry, it has a way to call the FeedCat method on the person.
The problem here is, only one person can feed the cat. Suppose you want multiple people to be able to feed the cat. People can be busy doing other things, so it's important for the cat to be able to tell multiple people that it's hungry. That way, people get notified of this, and they can check up on the cat when they have a chance, see if someone already fed the cat, and feed it if not.
Events to the rescue:
An event is basically a list of delegates (of a certain type). If you expose a Hungry event on your "Cat" class, multiple people can ADD pointers (delegates) to their FeedCat methods.
They can also remove the pointers (delegates) to their FeedCat methods if they like. Let's say a person moved out, and their sister is now taking care of the cat. The person can remove their delegate for their own FeedCat function from the cat, so that they no longer get notified that the darn cat is hungry.
Events vs. multicast delegates?
Technically, in order to be able to provide multiple delegates, you could use the so called MultiCastDelegates instead of events. They are composite delegates (a linked list or delegates). The problem there is, everyone can mess with them from the outside. An evil person could remove everyone else's "FeedCat" delegates, and the poor cat would starve (or would have to learn to hunt).
The important thing when using events is that the person cannot see other people's delegates that are added to the event, and it can't remove them or interact with them (in principle).

Exposing a (public) field
public EventHandler MyEventHandler;
is a bad practice: one can easily ruin the code with a small typo:
MyClass demo = new MyClass();
demo.MyEventHandler += MyMethod;
...
// Can you see the error? = instead of correct += ?
// MyMethod will not be called since this assignment
demo.MyEventHandler = MyReaction;
That's why you should use event which has been specially desinged for this
public event EventHandler MyEventHandler;
if we try the previous demo we'll get compile time error:
MyClass demo = new MyClass();
...
demo.MyEventHandler = MyReaction; // <- doesn't compile, insist on +=
In very rare cases you may want explicit delegate-based fields, but these field should be concealed, say, be private, not public:
// We don't expose the field
private EventHandler m_MyEventHandler;
// ... But event:
public event EventHandler MyEventHandler {
add {
//TODO: extra logic on += operation
m_MyEventHandler += value;
}
remove {
//TODO: extra logic on -= operation
m_MyEventHandler -= value;
}
}

DELEGATES, EVENTS(EVENT HANDLERS/EVENT LISTENERS), CONCEPTS(MULTICASTING/BROADCASTING), ACTION & FUNC
This will be a long one but its the simplest explanation, the problem this is such a nuisance of a topic is because people are just using different words to explain the same thing
First of all, you should know a few things
DELEGATES: It's nothing but a list of methods, why create a list? because when your code is being executed, that list is taken and every method there is executed one by one, just don't listen to textbook definitions take this and you will be all right
also called :
a pointer to a function
a wrapper for a method that can send and receive methods just like a variable
to create a delegate you go
[[access modifier] delegate [return type] [delegate name]([parameters])]
example: public delegate int demo(int a);
now to execute all these methods stored in a list called delegate, you go
1. demo.invoke(a);
2. demo(a); ..... both are valid
using the dot and explicitly saying invoke shines in async programming where you use beginInvoke, but that is out of the scope of this topic
there is one more thing called "Creating an object of the delegate/instantiate Delegate" which is pretty much as it sounds but just to avoid confusion it goes like (for the above example )
example : demo del = new demo(); (or) Public demo del = null;
to add any method to the list called delegate you go += and you also need to remove it once the "requirements of the methods are met" you go -=
(requirements of the methods are met mean you no longer need the method to be active or aka "listening") if you don't remove it, it could cause a "memory leak" meaning your computers ram will be eaten alive, technically allocated memory will not be released
example: say there is a method
public int calculate (int c)
to add this method to delegate you go
1. del = calculate;
2. del += calculate; .... all are valid
to remove
del -= calculate
first of all notice the similarities between the delegate and the method, the return type(output) and the input/parameters are the same, and that is a rule you just cannot add any random or a bunch of methods in a delegate it needs to follow the input-output rule
now why are there 2 different ways to do one thing, the only thing different is the assignment operators (+, =), this introduces a new topic called
EVENTS
which is nothing but a constrained version of a Delegate, It's still a List of methods don't confuse when people explain these terminologies, they change the name, so stick with this to understand
what is the constraint? you cannot do this del = calculate;
what's the harm in it, say a bunch of methods are added to the Delegate(List), you do that 👆 all are wiped out and only a single method "calculate" remains, so to prevent that Events are used,
Event Syntax
Public Event demo del = null;
One more thing you cannot do with events is invoke the delegate directly like demo.invoke since its public it can be accessed and invoked but with events, it can't
now you just add the methods to the event (a special type of delegate)
when to use an event vs a delegate, depends on your situation but pragmatically events are popular
few more keywords
MULTICASTING: nothing but adding more than one method to a delegate
BROADCASTING: adding more than one method to an event
PUBLISHER: the one that executes the method (term used in broadcasting), only a single entity
SUBSCRIBER: The methods that are being executed, can be multiple
LISTENER: the same thing as a subscriber but the term is used in multicasting
EVENT HANDLER: same thing as a subscriber/event listener so what the difference? it's basically the same thing, some say an eventlistener detect for the event to occur and the event handler "handles" or execute the code, ITS THE SAME THING PRACTICALLY!
action and func are just delegates that have been created and instantiated so 2 lines of code in a word, the difference is just in return types
ACTION: does not return anything while taking 0 or more than 1 input
FUNC: returns one thing and takes in parameters
if you don't do good with reading here is the best video on this topic
https://www.youtube.com/playlist?list=PLFt_AvWsXl0dliMtpZC8Qd_ru26785Ih_

How to create a callback variable in C# (true singlecast delegate)

How in C# do you create a true singlecast delegate. i.e a delegate instance that can reference one (and only one) method in its invocation list and so be used as a callback (for a single subscriber) rather than an event (which may have many subscribers).
The Framework has the classes System.Delegate and System.MulticastDelegate, which gives the mistaken impression that System.Delegate is singlecast and System.Multicast delegate adds multicast capability. But the MSDN documentation for System.Delegate http://msdn.microsoft.com/en-us/library/system.delegate.aspx indicates that System.Delegate is in fact multicast...
"The invocation list of a delegate is an ordered set of delegates in which each element of the list invokes exactly one of the methods represented by the delegate."
...while the documentation for System.MulticastDelegate does not really explain what extra behaviour it provides.
The official documentation in this area is pretty confusing, but one thing which is clear is that end-users cannot derive from either System.Delegate or System.MulticastDelegate. So is there any way supported by the framework to create a true singlecast delegate that can be used as a variable to store a reference to a single callback?
#dtb. If I can use a singlecast delegate then the need for the runtime check is eliminated. Of course it's true that the application logic could still fail in other ways, such as the wrong handler being assigned, but at least if I use a singlecast delegate then the problem of there being multiple handlers where I only expect one is one problem that simply cannot exist, hence there is one less thing to check, simpler unit tests, more elegant design. Also if a delegate for a method with a return value has multiple handlers in its invocation list, then it is the value returned by the last handler in the list that is returned to the caller, not the first.

If you really need a "singlecast" delegate with an event why don't you simply implement your own add/remove methods for that event?
The "problem" of Delegate is that MulticastDelegate is a derived class so if anyone assigns a MulticastDelegate object to a Delegate variable then you'll always have a MulticastDelegate.
For example we can simplify the default event implementation to this:
private ChangedEventHandler _changed;
public event ChangedEventHandler Changed
{
add
{
_changed += value;
}
remove
{
_changed -= value;
}
}
Now let's change the event implementation to:
private ChangedEventHandler _changed;
public event ChangedEventHandler Changed
{
add
{
_changed = value; // Do NOT combine delegates
}
remove
{
_changed -= value;
}
}
Now what you have is (almost) a singlecast delegate, because of event syntax users can't assign directly a multicast delegate and only the last assigned delegate is stored. If your users are really malicious they can create a MulticastDelegate and then add that delegate to your event handler. If you really need to prevent this you may add this check to the add method:
if (value.GetInvocationList().Length > 1)
throw new ArgumentException("MulticastDelegates are not allowed here.");

It's a bit more awkward than using a delegate, but one approach is to pass a callback interface with the method you want. Since there can only be a single implementation of the method, only one callback can be registered.
public interface IDoSomething
{
void DoSomething();
}
public sealed class MyClass
{
private IDoSomething _doer;
//We use a Set method rather than a property to prevent other classes from accessing the callback
//Another common (and generally better) pattern is to pass the instance into the constructor
public void SetSomethingDoer(IDoSomething doer)
{
_doer = doer;
}
//Other code can now access _doer to call back the method
}
This has the side benefit of allowing you to group multiple callback methods together, which often makes sense in these cases where you're trying to guarantee a single callback handler.

Why do Events need Delegates? Why do we even Need Events?

I've been confused over the past weeks now about events. I understand how delegates work, not how it works in detail but enough to know that
delegate datatype is a single cast delegate.
delegate void is a multicast delegate - a list of references to methods.
I know a delegate type compiles to a class, but unfortunately I am still not sure how the method is referenced. For example
delegate void TestDelegate();
TestDelegate testDelegate = new TestDelegate(myObject.SomeMethod) ;
Question 1: I think myObject is the target, and SomeMethod is the method to reference, but I'm only passing one input.
So is myObject.SomeMethod compiled to a string and is the string split by the period? Ridiculous I know.
Question 2:
When you add to a multicast delegate
multicastdelegate+=newmethodtobereference
multicastdelegate() ;
Every method in the invocation list is called or notified?
If that's true, why the hell do I need events or the event keyword? Is it simply to tell the developers that Hey, this is acting as an event? Because I'm seriously confused, I just want to move on at this stage lol. This is a sample code I wrote to test it today whether I need event keyword or not.
using System;
namespace LambdasETs
{
public delegate void IsEvenNumberEventHandler(int numberThatIsEven);
public class IsEvenNumberFound
{
public IsEvenNumberEventHandler IsEvenNumberEvent;
private int number;
public void InputNumber(int n)
{
if(number %2 ==0)
{
if (IsEvenNumberEvent != null)
{
IsEvenNumberEvent(n);
}
}
}
public static void Main()
{
IsEvenNumberFound isEvenNumberFound = new IsEvenNumberFound();
isEvenNumberFound.IsEvenNumberEvent += IsEvenNumberAction;
isEvenNumberFound.InputNumber(10);
Console.ReadLine();
}
public static void IsEvenNumberAction(int number)
{
Console.WriteLine("{0} is an even number!", number);
}
}
}
Adding the event keyword to the field public IsEvenNumberEventHandler IsEvenNumberEvent; has no difference.
Please can some explain so that a noob can understand thanks.

An event is an accessor for a delegate, just like a property is an accessor for a field. With much the same goals, it prevents other code from messing with the delegate object. Like setting it null when a bunch of code you don't know about have subscribed a callback. An event restricts access to only adding and removing event handlers with the += and -= operators, external code cannot access the private delegate object at all.
And to customize the subscription with the add and remove accessors. You don't often do so because you are typically happy with the default accessors generated by the compiler. Including a hidden backing field that stores a delegate. But it is not uncommon in the framework code for example. Like all the event handlers for the many events that System.Windows.Forms.Control supports, they are all stored in a single EventHandlerList. Or the WPF equivalent, EventHandlersStore.

but enough to know that delegate datatype is a single cast delegate. delegate void is a multicast delegate - a list of references to methods.
Not true. All "normal" delegates are multicast, even if they have a non void return type.
Question 1: I think myObject is the target, and SomeMethod is the method to reference, but I'm only passing one input. So is myObject.SomeMethod compiled to a string and is the string split by the period? Ridiculous I know.
No, myObject.SomeMethod is a method group. This way of delegate instance creation involves a bit of compiler magic.
multicastdelegate+=newmethodtobereference
If multicastdelegate is a normal delegate variable, this is equivalent to multicastdelegate = multicastdelegate + newmethodtobereference i.e. it creates a new delegate that calls several methods, and assigns it to multicastdelegate.
Now to your main question: What's the purpose of events?
Events have delegate types. They behave similarly to properties. Their purpose is encapsulation, in particular they only allow consumers to subscribe(+=) and unsubscribe(-=) but not to read the value of the event.
Properties are a combination of two methods: get and set.
Events are a combination of two public methods subscribe and unsubscribe, and in the case of a field-like event also something similar to a private getter.

different delegate uses

Possible Duplicate:
What is the difference between a delegate and events?
Possible Duplicate:
Difference between events and delegates and its respective applications
(copied from this duplicate)
When i have to raise an event i do this
public delegate void LogUserActivity(Guid orderGUID);
public event LogUserActivity ActivityLog;
even this works
public delegate void LogUserActivity(Guid orderGUID);
public LogUserActivity ActivityLog;
What is the difference between two of them

There are three things here:
Declaring a delegate type
Creating a public variable of a delegate type
Creating a public event of a delegate type
The variable is just a normal variable - anyone can read from it, assign to it etc. An event only exposes subscribe/unsubscribe abilities to the outside world. A field-like event as you've shown here effectively has a "default" subscribe/unsubscribe behaviour, stored in a field with the same name. Within the declaring class, you access the field; outside you access the event.
I have an article about events and delegates which explains in more detail.
EDIT: To answer the comment, you can easily initialize a field-like event with a "no-op" handler:
public event LogUserActivity ActivityLog = delegate{};

Events and public delegates differ in one big way that keeps me from using public delegates in most cases:
Event:
obj.ActivityLog = null; // invalid
Public Delegate:
obj.ActivityLog = null; // valid
This matters, because I only want the subscriber to add/remove themselves from the list in most cases. I don't want other objects unhooking events from other subscribers.
In cases where the delegate is less of an event and more of a callback, I tend to use public methods to do this and keep the public delegate from being exposed directly:
obj.RegisterActivityCallback(...)

An event is an abstraction over a delegate, just as a property is an abstraction over a field. And - just like a property - an event allows you to gain fine control over what happens when a handler is added/removed:
public event LogUserActivity ActivityLog
{
add { ... }
remove { ... }
}
Indeed, your event may not have a delegate backing it at all, just like a property may not necessarily have a field backing it.

In the first case you can assign multiple listeners to your ActivityLog event as in:
logger.ActivityLog += new LogUserActivity(Listener1);
logger.ActivityLog += new LogUserActivity(Listener2);
Both methods (Listener1 and Listener2) will be called when the event is fired. In the second case you are not creating an event but a delegate. In this case you can only assign one listener:
logger.ActivityLog = new LogUserActivity(Listener1);
In this case you do not fire an event but instead you call the delegate. An event is really just a chain of delegates that are called in turn.

to add to all the previous answers, An event IS a delegate, of a specific type. A delegate is a type that is designed to act as a "smart" function pointer, or, putting it another way, as a smart "wrapper" for a function pointer, that allows the compiler to intelligently decide at compile time whether the function(s) you are sticking into the delegate are consistent with the uses you are making of the delegate (consistency is based on the function signature).
An event is a delegate with a specific signature, specifically, one that does not return anything (returns void), and takes two parameters, a System.object, to hold a reference to whatever object triggered the event, and an instance of some type derived from System.EventArgs, to hold whatever other data the event needs to carry with it from the initialtor to the handler.