Actions replace old delegate event system?

[codeBeast]

Hi, I'm reading about the Action<> delegate (for registering events) that replaces the old delegate event way of doing things. So my only question is, do we not needed delegates anymore? Or are they still used for things other than events?

 

[Skydiver]

Can you provide a link to where you are reading this?

 

[Skydiver]

And yes, delegates are used elsewhere other than for events:

Control.Invoke Method (System.Windows.Forms)

Executes a delegate on the thread that owns the control's underlying window handle.

docs.microsoft.com

Marshalling a Delegate as a Callback Method - .NET Framework

Learn to marshal a delegate as a callback method. See an example of how to pass delegates to an unmanaged function that's expecting function pointers.

docs.microsoft.com

 

[jmcilhinney]

You say that you're reading about Action delegates and then ask whether we need delegates any more. You seem to have answered your own question.

It helps to understand what a delegate is and what an event is, so you understand how the inner working relate to what we see on the outside. The term "delegate" is used to refer to types and objects. Delegate types are special classes that can refer to methods with particular signatures. A delegate object is an instance of one of those types. For instance, the Action delegate can refer to methods with no parameters and that do not return anything. The Comparison<T> delegate can refer to methods that have two parameters of type T, i.e. any type but both the same, and that return an int. The EventHandler delegate can refer to methods that have two parameters of type object and EventArgs and that do not return anything. Etc.

An event is basically a special property that refers to a collection of delegates. The act of raising an event actual involves looping through the delegates in that collection and invoking each one. Invoking a delegate means executing the method it refers to.

What you have been reading about is almost certainly just the use of a Lambda expression as the method referred to by an event delegate instead of a named method. The actual event mechanism doesn't change in any way. In both cases, you create an appropriate delegate and that gets added to the collection of delegates stored in the event. Look at this code:

private void Form1_Load(object sender, EventArgs e)
{
    var btn1 = new Button {Text = "Button1"};

    btn1.SetBounds(10, 10, 100, 25);
    btn1.Click += Button_Click;

    var btn2 = new Button {Text = "Button2"};

    btn2.SetBounds(10, 50, 100, 25);
    btn2.Click += (s, ea) => Console.WriteLine("Click via Lambda expression");

    Controls.AddRange(new[] {btn1, btn2});
}

private void Button_Click(object sender, EventArgs e)
{
    Console.WriteLine("Click via named method");
}

One event handler is created from a named method and the other is created from a Lambda expression but the events don't care. In both cases, they simply add a delegate to their collection and then invoke it when the event is raised.

 

[JohnH]

If you need to remove the event handler later you need the delegate instance, and that can only be done like this:

EventHandler eh = (s, ea) => Console.WriteLine("Click via Lambda expression");
btn2.Click += eh;

Here you see what happened in previous example, the lambda expression was implicitly converted to an EventHandler instance.
If you were to try Action<object, EventArgs> lambda = (s, ea) => { }; you would find that it can not be conververted to EventHandler neither implicitly nor explicitly.
So even if you start assigning lambdas to events you are not rid of the EventHandler type (or other event delegate types).