[C#] Events uniform benaderen

[Orphix]

Hoi /14

Omdat ik in een testmodule graag wil testen op de gebeurtenissen van events binnen een bepaalde time-out, wil ik graag die events koppelen aan een algemene wachtfunctie (=eventhandler)
Deze wachtfunctie is van het type System.EventHandler; de meest algemene no-data eventhandler in het framework.

Echter wat is nou het geval, de applicatie gebruikt ook eventhandlers waarbij event data wordt meegegeven (afgeleiden van System.EventArgs). De functie maakt geen gebruik van die event-data. Deze geeft simpelweg een pulse aan een 'ManualResetEvent' object dat de acties is geslaagd (immers het event is aangeroepen).

Maar nu kan ik dus mijn simpele EventHandler niet koppelen aan de specifiekere events. Dit vind ik vreemd, want in principe voldoet mijn EventHandler gewoon aan de gestelde eisen (eerste parameter een object, tweede parameter een EventArg). Maar dat schijnt dus niet te kunnen.

Ik krijg dan deze melding:

code:

Cannot convert type 'System.EventHandler' to 'DataChangedEventHandler'

Is hier een oplossing voor? Anders zou ik dus voor elk type event een apart handler moeten schrijven, wat ik liever vermijd. Ik wil gewoon alle events met dezelfde handler opvangen.

[EfBe]

Jouw event is niet met EventHandler gedefinieerd. Dit betekend dat de signature van de delegate die je gebruikt, DataChangedEventHandler, niet overeenkomt met de EventHandler delegate. Vandaar dat je dan dus niet een routine die de signature van EventHandler heeft kunt gebruiken voor het afhandelen van die events.

Als je alle events met 1 handler wilt opvangen, wat op zich logisch is, je schrijft je een ongeluk aan eventargs, is op te lossen door een soort container event args te maken waar je allerlei info in kwijt kunt. Immers, de eventargs verschillen per event. Daarna maak je een delegate met die eventargs en je kunt ieder event zn eigen gegevens mee laten sturen en toch met 1 handler type ze afvangen.

[Orphix]

EfBe schreef op zaterdag 22 januari 2005 @ 09:41:
Jouw event is niet met EventHandler gedefinieerd. Dit betekend dat de signature van de delegate die je gebruikt, DataChangedEventHandler, niet overeenkomt met de EventHandler delegate. Vandaar dat je dan dus niet een routine die de signature van EventHandler heeft kunt gebruiken voor het afhandelen van die events.

Ja dat begrijp ik. Ik vind het alleen jammer dat de compiler niet zo slim is om in te zien dat die conversie in feite wel geldig is. Immers bij mijn eventhandler gaat er enkel informatie verloren (van de specifieke data eventargs), maar ik verwacht niet bepaalde informatie. Eigenlijk zou je delegates net als classes moeten kunnen deriven van bijvoorbeeld EventHandler.

Als je alle events met 1 handler wilt opvangen, wat op zich logisch is, je schrijft je een ongeluk aan eventargs, is op te lossen door een soort container event args te maken waar je allerlei info in kwijt kunt. Immers, de eventargs verschillen per event. Daarna maak je een delegate met die eventargs en je kunt ieder event zn eigen gegevens mee laten sturen en toch met 1 handler type ze afvangen.

Ja dat is een oplossing. Ware het niet dat ik het voor de applicatie programmeur, die de library gebruikt, het veel netter vindt om specifieke EventArgs mee te geven in plaats van een zeer algemene container waarbij de programmeur dan zelf moet uitzoeken welke data nou eigenlijk wordt meegegeven, welke velden valide zijn en welke niet, etc.
Het is een probleem waarbij ik dus vooral bij het testen mee zit. Dan heb ik al die extra info niet nodig, ik wil alleen weten of het gebeurt.

Ik heb het ondertussen maar opgelost met een zooi specifieke eventhandlers die dan die generieke wachtfunctie elke keer aanroepen. Dit is ism IntelliSense e.d. nog wel te doen, maar netjes is anders

[Korben]

Je zou in principe een compromis moeten sluiten. Als je kijkt naar het .NET framework zelf, zie je dat ze voor elk soort event een aparte EventArgs hebben gemaakt, behalve voor events die erg veel op elkaar lijken, zoals bijvoorbeeld bij de FileSystemWatcher events. Wellicht zou je zoiets kunnen proberen, de programmeur komt er dan toch wel snel achter welke velden wel en niet bruikbaar zijn bij bepaalde events. Het is inderdaad jammer dat delegates niet inheritable zijn, maar het is helaas niet anders.