Object reference in delegate declaration

Is it really needed all the time?

Page 1 of 1

2 Replies - 2318 Views - Last Post: 25 February 2010 - 11:26 AM Rate Topic: -----

#1 valeriano   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 15
  • Joined: 10-February 10

Object reference in delegate declaration

Posted 25 February 2010 - 09:57 AM

Hello. I'm now learning about delegates and events, using Learning C# 3.0, from O'Reilly that I borrowed from a friend, since my C# 3.0 - A Beginner's Guide is not very "beginner friendly" on that part. The thing is that I'm actually understanding it now, and enjoying it.

A quick question that my friend (and none of the books) could answer about it:

Do I really need to use the object reference on a delegate declaration every time? I think it is probably required when using Windows Forms but I'm talking about console applications here, since that's how this book teaches. Here's an example:

//declaring delegate and event
public delegate void SecondChangeHandler(object theClock, TimeEventArgs timeInfo);
public event SecondChangeHandler SecondChanged;

//later on, raising the event
SecondChanged(this, timeInfo);



It's the classic clock tick example, where the console will display the time every second passed.

After reading the example, typing it myself in VS, and successfully running it, only the reference to the object (both in the declaration and in the event calling) were not clear to me, since they were not used in the code. Then I tried removing the references in the code, and it worked:

//declaring delegate and event
public delegate void SecondChangeHandler(TimeEventArgs timeInfo);
public event SecondChangeHandler SecondChanged;

//later on, raising the event
SecondChanged(timeInfo);



Everything worked as intended, without any side effects caused by the removal of the object reference. I had to change the methods in the classes that would subscribe to the event, to match the number of arguments, but that was all.

So... is it a rule to include the reference or something like that? I know it is possible to make use of the object reference in some cases, but in this simple example, it wasn't needed and the author included it anyway.

Thanks in advance.


EDIT:

Reading through the chapter again, I spotted this:

Quote

By convention, event handlers in the .NET Framework always return void and take
two parameters. The first parameter is the “source” of the event (that is, the publishing
object). The second parameter is an object derived from EventArgs. Your event
handlers will need to follow this design pattern.


So he says that my event handlers will need to follow this "rule", that is actually a convention. Still a bit confused by this. :blink:

This post has been edited by valeriano: 25 February 2010 - 10:16 AM


Is This A Good Question/Topic? 0
  • +

Replies To: Object reference in delegate declaration

#2 MentalFloss   User is online

  • .
  • member icon

Reputation: 584
  • View blog
  • Posts: 1,527
  • Joined: 02-September 09

Re: Object reference in delegate declaration

Posted 25 February 2010 - 10:56 AM

Yes, the rule of thumb is that you pass (in this order) object, EventArgs. That's the pattern anyway. The reason for the object portion is because it's generally the sender of the event (the object that raises the event). This way, the receiving code is able to dissect the sender and put logic behind the result.

Anyway, another rule of thumb is that if event itself carries no state - meaning that it only matters that an event was raised - then you shouldn't bother with creating your own delegate. You should just use the standard existing EventHandler delegate.

When you need to retrieve data from the raised event such as some text or results of a calculation or whatever, then you need to create a new class that inherits from EventArgs. This class would have its own properties to store the data.

Do you really need to? No. Do you even need a method to handle it? No, Check this out:

button1.Click += delegate(object sender, EventArgs e){ MessageBox.Show("You clicked the button."); };



This is an anonymous method. The code that will run when that button is clicked is inline to the call itself. The trade-off? You can never dissociate this event handler to the event for the life of the application.

Anyway, glad you're taking time to understand events, delegates, and such. I made another post about this that went into a lot of detail. Please take a look at it and see if it helps you as well.

http://www.dreaminco...35&#entry931335

This post has been edited by MentalFloss: 25 February 2010 - 11:00 AM

Was This Post Helpful? 1
  • +
  • -

#3 valeriano   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 15
  • Joined: 10-February 10

Re: Object reference in delegate declaration

Posted 25 February 2010 - 11:26 AM

Ohhh I see it now!

So the author only created a new delegate to exemplify maybe? I could have just used:

public event System.EventHandler SecondChanged;



Or no handler at all, like you said. These anonymous methods are great stuff. And I must confess I did not know there was a default EventHandler either. This makes things way more clear.

And now I also understand why I should use the reference (when using the System.EventHandler anyway), it is on the signature for the default delegate.

Thanks for the info mate, I think I have complete understanding of delegates/events now. This topic was so blurry and confuse that I was thinking about skipping it completely!

Now... on to LINQ. Later!

This post has been edited by valeriano: 25 February 2010 - 11:27 AM

Was This Post Helpful? 0
  • +
  • -

Page 1 of 1