Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Events that conform to Net guidelines - I don't see the benefits

Status
Not open for further replies.

beginwithl

Programmer
Jan 11, 2009
2
SI
hi

First I’d like to point out that I do understand how to use Events according to Net Framework guidelines, I just don’t understand the benefits of this Event pattern


From MSDN site:

"The .NET Framework guidelines indicate that the delegate type used for an event should take two parameters, an "object source" parameter indicating the source of the event, and an "e" parameter that encapsulates any additional information about the event. The type of
the "e" parameter should derive from the EventArgs class. For events that do not use any additional information, the .NET Framework has already defined an appropriate delegate type: EventHandler."


a) I don’t understand why it would be so much more useful for all the delegate types used for events to have the same first parameter, and having EventArgs or class derived from it as a second parameter?


b) Whatever the benefits may be, why would they out-weight the trouble of having to:

- write an additional code to put the desired arguments into an object ( of type derived from EventArgs ) that will be passed as an argument when event is fired

- write an additional code inside event handlers to extract
information from objects ( of types derived from EventArgs)

?

thank you
 
It's the whole concept of OOP. If you are sending/receiving arguments from an event of some kind, it makes sense that they should be EventArgs or a child of EventArgs, so that existing code that handles EventArgs can handle your new ones.

For example if I wanted to write an event tracer of some kind I could have 1 routine that takes an EventArgs object, uses reflection to loop through the properties/fields, and writes to a trace file.

Also - maybe more important is that EventArgs might be the parent of, say, AnimalEventArgs which might be the parent of DogEventArgs, CatEventArgs, ElephantEventArgs, etc. You could raise an event and pass any one of these arguments to the same routine if it takes EventArgs, whereas if you had separate routines - 1 that took objDog, one that took objCat, 1 that took objElephant, etc you would need to code loads of routines that essentially do the same thing.

Not the best examples but hope it helps!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top