La compréhension des événements et des gestionnaires d'événements en C#

De comprendre les gestionnaires d'événements, vous devez comprendre les délégués. Dans C#, vous pouvez penser à un délégué comme un pointeur (ou une référence) à une méthode. Ceci est utile parce que le pointeur peut être adopté comme une valeur.

Le concept central d'un délégué est sa signature, ou de la forme. C'est (1) le type de retour et (2) les arguments d'entrée. Par exemple, si nous créons un délégué void MyDelegate(object sender, EventArgs e), il ne peut point des méthodes qui renvoient des void, et de prendre une object et EventArgs. Un peu comme un trou carré et une cheville carrée. Donc nous disons que ces méthodes ont la même signature, ou de la forme, en tant que délégué.

Donc savoir comment faire pour créer une référence à une méthode, nous allons réfléchir à la finalité des événements: nous voulons provoquer un peu de code à exécuter lorsque quelque chose se passe ailleurs dans le système - ou "gérer l'événement". Pour ce faire, nous créons des méthodes spécifiques pour le code que nous voulons être exécuté. La colle entre les événements et les méthodes à exécuter sont les délégués. L'événement doit en interne stocker une "liste" de pointeurs vers les méthodes à appeler lorsque l'événement est déclenché.* Bien sûr, pour être en mesure d'appeler une méthode, nous avons besoin de savoir quels sont les arguments à passer! Nous utilisons le délégué, le "contrat" entre l'événement et toutes les méthodes qui seront appelées.

Donc la valeur par défaut EventHandler (et beaucoup d'autres) représente un forme spécifique de la méthode (encore une fois, nulle/objet-EventArgs). Lorsque vous déclarez un événement, vous dites la forme de la méthode (Gestionnaire) que l'événement va invoquer, en spécifiant un délégué:

//This delegate can be used to point to methods
//which return void and take a string.
public delegate void MyEventHandler(string foo);

//This event can cause any method which conforms
//to MyEventHandler to be called.
public event MyEventHandler SomethingHappened;

//Here is some code I want to be executed
//when SomethingHappened fires.
void HandleSomethingHappened(string foo)
{
    //Do some stuff
}

//I am creating a delegate (pointer) to HandleSomethingHappened
//and adding it to SomethingHappened's list of "Event Handlers".
myObj.SomethingHappened += new MyEventHandler(HandleSomethingHappened);

//To raise the event within a method.
SomethingHappened("bar");

(*C'est la clé d'événements .NET et des peelings à l'écart de la "magie" - un événement est vraiment, sous les couvertures, juste une liste des méthodes de la même "forme". La liste est stockée dans lequel l'événement de vie. Lorsque l'événement est "élevé", c'est vraiment juste "passer à travers cette liste de méthodes et d'appeler chacun, à l'aide de ces valeurs que les paramètres". Affectation d'un gestionnaire d'événements est juste une plus belle, la plus facile d'ajouter votre méthode pour cette liste de méthodes pour être appelé).

Voici un exemple de code qui peuvent vous aider:

using System;
using System.Collections.Generic;
using System.Text;
namespace Event_Example
{
//First we have to define a delegate that acts as a signature for the
//function that is ultimately called when the event is triggered.
//You will notice that the second parameter is of MyEventArgs type.
//This object will contain information about the triggered event.
public delegate void MyEventHandler(object source, MyEventArgs e);
//This is a class which describes the event to the class that receives it.
//An EventArgs class must always derive from System.EventArgs.
public class MyEventArgs : EventArgs
{
private string EventInfo;
public MyEventArgs(string Text) {
EventInfo = Text;
}
public string GetInfo() {
return EventInfo;
}
}
//This next class is the one which contains an event and triggers it
//once an action is performed. For example, lets trigger this event
//once a variable is incremented over a particular value. Notice the
//event uses the MyEventHandler delegate to create a signature
//for the called function.
public class MyClass
{
public event MyEventHandler OnMaximum;
private int i;
private int Maximum = 10;
public int MyValue
{
get { return i; }
set
{
if(value <= Maximum) {
i = value;
}
else 
{
//To make sure we only trigger the event if a handler is present
//we check the event to make sure it's not null.
if(OnMaximum != null) {
OnMaximum(this, new MyEventArgs("You've entered " +
value.ToString() +
", but the maximum is " +
Maximum.ToString()));
}
}
}
}
}
class Program
{
//This is the actual method that will be assigned to the event handler
//within the above class. This is where we perform an action once the
//event has been triggered.
static void MaximumReached(object source, MyEventArgs e) {
Console.WriteLine(e.GetInfo());
}
static void Main(string[] args) {
//Now lets test the event contained in the above class.
MyClass MyObject = new MyClass();
MyObject.OnMaximum += new MyEventHandler(MaximumReached);
for(int x = 0; x <= 15; x++) {
MyObject.MyValue = x;
}
Console.ReadLine();
}
}
}

Juste pour ajouter à l'existant de grandes réponses ici - en s'appuyant sur le code de la accepté de, qui utilise un delegate void MyEventHandler(string foo)...

Parce que le compilateur connaît le type de délégué de la SomethingHappened événement, ce:

myObj.SomethingHappened += HandleSomethingHappened;

Est totalement équivalent à:

myObj.SomethingHappened += new MyEventHandler(HandleSomethingHappened);

Et les gestionnaires peuvent également être non avec -= comme ceci:

//-= removes the handler from the event's list of "listeners":
myObj.SomethingHappened -= HandleSomethingHappened;

À des fins d'exhaustivité, de sensibilisation de l'événement peut être fait comme ceci, uniquement dans la classe qui est propriétaire de l'événement:

//Firing the event is done by simply providing the arguments to the event:
var handler = SomethingHappened; //thread-local copy of the event
if (handler != null) //the event is null if there are no listeners!
{
handler("Hi there!");
}

Le fil-d'une copie locale du gestionnaire est nécessaire pour s'assurer que l'invocation est thread-safe, sinon un thread pourrait aller et annuler l'inscription de la dernière gestionnaire pour l'événement immédiatement après, nous avons vérifié si c'était null, et nous aurions un "plaisir" NullReferenceException là.

C# 6 a introduit un joli court de la main pour ce modèle. Il utilise le nul de la propagation de l'opérateur.

SomethingHappened?.Invoke("Hi there!");

editeur: où les événements se produisent. Éditeur doit spécifier le délégué de la classe et de générer des arguments nécessaires, passer ces arguments et lui-même pour le délégué.

abonné: lorsque la réponse arrive. L'abonné doit préciser les méthodes à réagir à des événements. Ces méthodes devraient prendre le même type d'arguments que le délégué. Abonné ajoutez ensuite cette méthode à l'éditeur délégué.

Par conséquent, lorsque l'événement se produire dans l'éditeur, délégué recevra certains arguments d'événement (données, etc), mais l'éditeur n'a aucune idée de ce qui va arriver avec toutes ces données. Les abonnés peuvent créer des méthodes dans leur propre classe pour répondre à des événements dans l'éditeur de la classe, afin que les abonnés puissent répondre à l'éditeur d'événements.

Je suis d'accord avec KE50 sauf que j'ai vue de l '"événement" mot-clé comme un alias pour "ActionCollection' depuis l'événement dispose d'un ensemble d'actions à effectuer (ie. le délégué).

using System;
namespace test{
class MyTestApp{
//The Event Handler declaration
public delegate void EventAction();
//The Event Action Collection 
//Equivalent to 
// public List<EventAction> EventActions=new List<EventAction>();
//       
public event EventAction EventActions;
//An Action
public void Hello(){
Console.WriteLine("Hello World of events!");
}
//Another Action
public void Goodbye(){
Console.WriteLine("Goodbye Cruel World of events!");
}
public static void Main(){
MyTestApp TestApp = new MyTestApp();
//Add actions to the collection
TestApp.EventActions += TestApp.Hello;
TestApp.EventActions += TestApp.Goodbye;
//Invoke all event actions
if (TestApp.EventActions!= null){
//this peculiar syntax hides the invoke 
TestApp.EventActions();
//using the 'ActionCollection' idea:
//foreach(EventAction action in TestApp.EventActions)
//    action.Invoke();
}
}
}   
}

J'ai récemment fait un exemple de comment utiliser les événements en c#, et posté sur mon blog. J'ai essayé de la rendre aussi claire que possible, avec un exemple très simple. Dans le cas où ça pourrait aider quelqu'un, c'est ici: http://www.konsfik.com/using-events-in-csharp/

Il comprend la description et le code source (avec beaucoup de commentaires), et il se concentre principalement sur une bonne (template) de l'utilisation des événements et des gestionnaires d'événements.

Quelques points clés sont:

• Événements sont comme des "sous - types de délégués", n'est plus soumis à une contrainte (dans le bon sens). En fait, d'un événement, la déclaration comprend toujours un délégué (gestionnaires d'événements sont un type de délégué).

• Les Gestionnaires d'événements sont des types spécifiques de délégués (vous pouvez y penser comme à un modèle), ce qui force l'utilisateur à créer des événements qui ont une "signature". La signature est de la forme: (object sender, EventArgs eventarguments).

• Vous pouvez créer votre propre sous-classe EventArgs, afin d'inclure n'importe quel type d'informations de l'événement, il faut transmettre. Il n'est pas nécessaire d'utiliser des gestionnaires d'événements en utilisant des événements. Vous pouvez complètement les ignorer, et d'utiliser votre propre genre de déléguer à leur place.

• Une des principales différences entre l'utilisation des événements et des délégués, est que les événements ne peut être invoqué à partir de l'intérieur de la classe à laquelle ils ont été déclarés en, même si elles peuvent être déclarées comme public. C'est une distinction très importante, car elle permet à vos événements à être exposé, de sorte qu'ils sont "connectés" à l'externe des méthodes, tandis que dans le même temps, ils sont protégés de l'externe "utilisation abusive".