sciencetalk

Weet iemand meer over dit onderwerp?

Al eens op google gezocht? Dat levert je 250,000 resultaten op.

Google is ook niet alles.

Over delegates en events kun je een heel dik boek schrijven en dan nog heb je niet alles beschreven. Je zult veel specifieker moeten zijn met je vraag. Als je "iets" over events wilt weten dan is google je vriend, of anders een boek over C# in de bibliotheek of boekhandel. Heb je een specifieke vraag, dan kun je het wellicht hier proberen.

Nou dit is het algemene beeld:

Objectgeorienteerde talen zijn gestructureerd in klassen, wanneer programma's uitgevoerd worden worden er objecten aangemaakt die behoren tot die klassen, maar soms dienen boodschappen overgebracht te worden van het ene naar het andere object. Meestal wordt dit gedaan door middel van methode-oproepen, of in C# dus ook via veranderingen op eigenschappen (properties).

Soms echter dient een object een boodschap te sturen, maar weet het nog niet aan wie (welke objecten dus). Dat is ongeveer het doel van events. Stel je definieerd een knop (System.Windows.Forms.Button) op het moment dat je die knop aanklikt is het normaal dat er iets gebeurt, de programmeur die de knop definieerde weet echter niet welke methode hij dient aan te spreken (dat hangt immers af van wat je wil doen). Er is dus een event gedefineerd in button, die aangeroepen wordt op het moment dat je klikt. (Button.Click) Click is een standaard event, en is gelinkt met de EventHandler-delegate, een delegate zonder argumenten. Stel je hebt een methode X die je wilt aanroepen indien er geklikt wordt dan voeg je deze toe aan de click-event:
Je maakt dus een eventhandler aan die gelinkt is aan de de methode X. Die eventhandler voeg je toe aan de event-lijst van Button.Click.

op het moment dat je klikt gaat de event alle delegates die opgeslagen zijn in de event af, en deze doen een invoke-operatie op de methodes. M.a.w. indien er geklikt wordt, zal methode X aangeroepen worden

De delegate bepaald de argumenten van de methodes die toegevoegd worden. En deze worden ook gecontroleerd door de compiler, het is dus een veilige manier van methode-invoke functies. In plaats van System.Runtime.InteropServices.

stel dat je zelf een event aanmaakt laat ons zeggen E, dan roep je deze als volgt op:
Een event defineer je als een veld met volgende syntax
Bij System.Windows.Forms ziet de declaratie er dus als volgt uit:
Een delegate is een soort klasse en zoals al gezegd wordt een delegate dus gebruikt om de parametertypes te definieren, een voorbeeld:
void-wijst op het retourneertype, alleen methodes met als parameters één string mogen dus toegevoegd worden.

stel we criëren een event "Ev" hiervoor dan zal de code dus zijn:
om hem op te roepen gebruiken we volgende syntax:
Dat is ongeveer de inleiding, maar uiteraard zit er nog veel meer achter, het is meer om je op weg te helpen.

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

Dit is niet correct. In .Net worden events vrijwel altijd als volgt gedefinieerd:
Oftewel, die hebben allemaal twee argumenten, en niet nul. De standaard EventHander heeft de volgende definitie:
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):
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:

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

Code: Selecteer alles

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

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

Code: Selecteer alles

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

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.

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

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

• 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.

Als je bestaande events wilt gebruiken, dan geldt:

• 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]

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.

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, 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.

Een delegate is GEEN klasse !!!

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

Aries schreef:Een delegate is GEEN klasse !!!

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

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.

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