Een delegate is een wijzer naar een functie, maar ook een klasse maar die discussie doet hier eigenlijk niet veel terzake. Een event zou je kunnen zien als een lijst van delegates, op het moment dat er iets aan de toestand van een object dat het belangrijk genoeg vindt om aan eventueel geïntresseerde objecten te laten weten zal hij het event oproepen, de event zal vervolgens alle delegates in zn lijst nagaan, en elke delegate oproepen, deze zullen dus vervolgens de functie die aan hun gelinkt is oproepen.

Een concreet voorbeeld, je maakt een form om bijvoorbeeld een contactpersoon toe te voegen, in dat form plaats je een Button waarop de gebruiker klikt wanneer hij gereed is, dan zou je in de implementatie van bijvoorbeeld de klasse Persoon (een object die je dus al gecriëerd hebt en waarvan je de naam, geboortedatum,... wil checken) dat natuurlijk graag weten, want het moet dan de informatie aanpassen, je kan dus een methode van de klasse persoon zeg maar de methode SetInformationWithInformationFromForm als Listener kunnen zien, je voegt deze toe aan de Click-event van de Button. Op het moment dat de gebruiker op de knop klikt zal de klasse Button het Click-Event activeren, de methode SetInformationWithInformationFromForm staat op de lijst, en zal dus opgeroepen worden, dat is ongeveer het principe.

Dus ik kan in mijn klasse een event maken, en dan mijn form laten abboneren op dat event. En vervolgens kan ik vanuit een methode op het form dat event aanroepen?

Ik snap er nog steeds niet veel van.

Het feit dat delegates niet alleen functiepointers zijn maar ook nog een groot aantal methodes hebben (http://msdn.microsoft.com/en-us/library/system.delegate_members.aspx) bewijst het tegendeel, een delegate is een klasse die een inheritance is van System.Delegate, in de klasse zelf bevindt zich een NATIVE pointer (daar dat alles toch ooit eens native moet worden). En uiteraard ook nog andere velden. Maar een delegate zelf is dus een klasse, het concept delegate is een functiepointer.

Dit is DE reden waarom veel mensen delegates niet begrijpen en met name met UML modellen in de knoei komen.

strict genomen is ALLES een klasse een int ook in C# (boxing) maar als je zo gaat denken ga je de mist in.

Een delegate is een functiepointer.. of anders een delegatie is een vertegewoordiging .. een delegate vertegenwoordigd een functie.

C# probeert alles heel OO te doen, dat betekent dat een struct bijvoorbeeld wel een klasse is die een inheritance van System.ValueType is, idem voor interface, enum, en dus ook delegate

[quote='Aries' post='540928' date='11 August 2009, 09:21']Een delegate is GEEN klasse !!!

het is een soort opgepimpte function pointer zoals je die in C++ ook gebruikt[/quote]

Vreemd, ik zocht op: Delegate class,about Delegate class

en kreeg o.a. dit:

The Delegate class is the base class for delegate types. However, only the system and compilers can derive explicitly from the Delegate class or from the MulticastDelegate class. It is also not permissible to derive a new type from a delegate type. The Delegate class is not considered a delegate type; it is a class used to derive delegate types.

;)

Een delegate is GEEN klasse !!!

het is een soort opgepimpte function pointer zoals je die in C++ ook gebruikt

Nou, de opdracht was juist dat er een event in moest, zoals ik omschreef, dus om dan een andere oplossing te bedenken is dan contraproductief he.

Dat hangt af van de implementatie uiteraard, maar volgens mij kan je door je model (UML) een beetje aan te passen, ook dit soort zaken door middel van een eenvoudige methode oproep afhandelen. Als je een veld definieerd bij je trein die het huidige station bijhoud en je definieerd methodes op het station als RegistreerTrein (bij aankomst) en SchrapTrein (bij vertrek) hoef je helemaal geen events te gebruiken. Het is natuurlijk de keuze van het model. Al weet ik natuurlijk niet hoe de rest van het model ineen zit. Events zijn bijvoorbeeld handig wanneer je niet weet aan wat voor object je je verstrek of aankomst wil melden: (een belachelijk voorbeeld) stel dat je aan de stad moet melden dat je binnenkomt of buitengaat en er nog zo'n aantal objecten zijn, dan zou dat op den duur een hele organisatie vragen om met types te werken en methodes op te vragen, in dat geval heb je voordeel aan een event. Maar events zijn niet altijd de oplossing voor problemen.

Nou, het idee is dat ik een eenvoudige treinsimulatie maak, en de trein moet een event kunnen genereren om het vertrek van en aankomst op een station te melden. De opdracht is verder niet gedefinieerd, dus dat kan naar eigen invulling neem ik aan.

Als je je eigen events wilt maken en zelf zorgt dat ze zich voordoen, dan geldt:

[list]

[*]Delegates (public delegate void EventHandler(...); ) moet je definiëren in een namespace, maar buiten elke klasse.

[*]Events (public event EventHandler MyEvent;[) moet je definiëren in een klasse.

[/list]

Als je bestaande events wilt gebruiken, dan geldt:

[list]

[*]Event handler methodes (public void myForm_Button(...) {...}) definieer je in een klasse van je keus, een klasse waarin je het object gebruikt dat de events genereert.

[*]Bindingen met de events (myForm.Button += new EventHandler(myForm_Button); ) stel je in in de constructor van de klasse waarin je de event handler methodes hebt gedefinieerd.
[/list][/list]

En waar zet ik die delegates en events neer? In het form?

[quote='virtlink' post='536547' date='26 July 2009, 10:42']Dit is niet correct. In .Net worden events vrijwel altijd als volgt gedefinieerd:

[code]public delegate void XYZEventHandler(object sender, XYZEventArgs e);[/code]

Oftewel, die hebben allemaal twee argumenten, en niet nul. De standaard EventHander heeft de volgende definitie:

[code]public delegate void EventHandler(object sender, EventArgs e);[/code][/quote]

mijn excuses dat was inderdaad een foutje van mij, enfin maar het was niet de bedoeling een opsomming van alle eventhandlers te geven, maar dus een algemeen beeld te geven wat events zijn en wat je ermee kunt doen, daar de TS zijn vraag niet verduidelijkte.

public delegate void XYZEventHandler(object sender, XYZEventArgs e);

public delegate void EventHandler(object sender, EventArgs e);

public void btnKnop_Click(object sender, EventArgs e)

{ /* Doe iets. */ }

public delegate void PingEventHandler(object sender, PingEventArgs e);

public class Pinger

{

public event Ping;

protected virtual void OnPing(PingEventArgs e)

{

if (Ping != null)

Ping(this, e);

}

public void PingMijEens(int getal)

{

OnPing(new PingEventArgs(getal));

}

}

[quote](Button.Click) Click is een standaard event, en is gelinkt met de EventHandler-delegate, een delegate zonder argumenten.[/quote]

Dit is niet correct. In .Net worden events vrijwel altijd als volgt gedefinieerd:

[code]public delegate void XYZEventHandler(object sender, XYZEventArgs e);[/code]

Oftewel, die hebben allemaal twee argumenten, en niet nul. De standaard EventHander heeft de volgende definitie:

[code]public delegate void EventHandler(object sender, EventArgs e);[/code]

Maak je een methode die moet kunnen worden aangeroepen door die delegate, dan moet deze dan ook voldoen aan de signatuur van de delegate, bijvoorbeeld (de naam is arbitrair, maar het return-type en de parameters niet):

[code]public void btnKnop_Click(object sender, EventArgs e)

{ /* Doe iets. */ }[/code]

Zoals Vladimir Lenin uitlegt is een delegate dus hoe .Net functiepointers implementeert. Delegates kan je ook zonder events gebruiken, bijvoorbeeld om C++ jumptable in C# te implementeren, als een array van delegates.

Als je zelf een event XYZ definieert, gebruik je een protected OnXYZ methode die je kan aanroepen om die event zich te laten voordoen. Bijvoorbeeld een event Ping, waarvoor we onze eigen event arguments PingEventArgs hebben gedefinieerd:

[code]public delegate void PingEventHandler(object sender, PingEventArgs e);

public class Pinger

{

public event Ping;

protected virtual void OnPing(PingEventArgs e)

{

if (Ping != null)

Ping(this, e);

}

public void PingMijEens(int getal)

{

OnPing(new PingEventArgs(getal));

}

}[/code]