Amil,
In this case, the EventArgs will not do anything for you. The reason
for this is that there is no extra information associated with the event
that you can't get from the sender parameter (which is the button that fired
the click).
The EventArgs instance is there so that you can observe the pattern laid
out for event signatures by MS when they created the framework. The pattern
basically is (and I'm sure you have seen this everywhere):
object sender; <EventArgs derived type> e
With .NET 2.0, this pattern is even more useful. The reason for this is
that there is now delegate covariance (I believe that is it), which means
that if you have a delegate that is expecting a signature of:
object sender, CancelEventArgs e // CancelEventArgs derives from EventArgs
You can assign a method with a signature of object, EventArgs to that
delegate, because it is possible to cast down the CancelEventArgs to an
EventArgs instance. This will allow you assign event handlers to more
delegates (depending on the logic you need to execute).
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
-
mv*@spam.guard. caspershouse.co m
"Amil" <Am**@discussio ns.microsoft.co m> wrote in message
news:3A******** *************** ***********@mic rosoft.com...
when i double-click on a button on a form as i am designing the form, the
IDE
creates a method corresponding to a event assignment as follows:
this eventhandler: this.exitToolSt ripMenuItem.Cli ck += new
System.EventHan dler(this.exitT oolStripMenuIte m_Click);
is paired with: private void exitToolStripMe nuItem_Click(ob ject sender,
EventArgs e) {}
How do/Can I what the EventArgs are?
