event arguments

[Pohihihi]

This might sound little stupid to many but I was thinking that when we can
use object why we really need event args to pass in any functions e.g.

bool MyFunction(object sender, System.EventArgs e){}

my question is targetted more on the customized event arguments that we
create while programming.
Is it just to make it more readable or maybe to make things in collective
and hierarchy?

Maybe this question it is very much like my previous post on why we need 3
diff kind of exception when they not doing any good. Basically all are
System.Exception.

System.Exception
System.SystemException
System.ApplicationException

And, if ApplicationException is there then what could have hurt adding
ConsoleException or WindowsApplicatoinException per say.

As per the following link (thanks to Jay Harlow)
http://blogs.msdn.com/brada/archive/.../25/96251.aspx

seems like no one likes to use ApplicationException.

If this is the feeling in general than why now just use

bool MyFunction(object sender, MyObject myObj){}

My point is that why even argument namespace anyways !

Thanks,
Po

[Pete Davis]

Largely it's a matter of good object oriented design, in answer to both your
questions.

In the case of events and event handlers, they're simply delegates. You
could pass anything for your own custom event handlers. In fact the samples
in the MSDN documentation for the event keyword has a number of different
delegates with different sets of parameters

The fact that the framework uses (object sender, EventArgs e) is a
convention they established and it tends to be a fairly good system. It
makes it pretty easy to deal with events in the framework because you don't
have to remember a bunch of different events with completely different
arguments. There's an established, easy to remember pattern.

As for exceptions, the argument is a bit different, but it's basically like
this: In general, you want to classify your exceptions by type. You don't
want to always throw an ApplicationException or Exception. You want to throw
an InvalidArgumentException if the arguments passed to a method are invalid,
or an IO based exception for IO problems.

This allows you to organize the handling in places that are appropriate,
based on the classification of the exception. It also allows you to handle
exceptions in terms of a group. For example, if you receive on kind of
exception, you may want to show a message to the user. The message may be
contained in the exception. For a different type of exception, you might
just want to log it to a file, but not notify the user of the exception.

Again, it's simply a matter of good OO design.

Pete

"Pohihihi" <po******@hotmail.com> wrote in message
news:ui*************@TK2MSFTNGP15.phx.gbl...

This might sound little stupid to many but I was thinking that when we can
use object why we really need event args to pass in any functions e.g.

bool MyFunction(object sender, System.EventArgs e){}

my question is targetted more on the customized event arguments that we
create while programming.
Is it just to make it more readable or maybe to make things in collective
and hierarchy?

Maybe this question it is very much like my previous post on why we need 3
diff kind of exception when they not doing any good. Basically all are
System.Exception.

System.Exception
System.SystemException
System.ApplicationException

And, if ApplicationException is there then what could have hurt adding
ConsoleException or WindowsApplicatoinException per say.

As per the following link (thanks to Jay Harlow)
http://blogs.msdn.com/brada/archive/.../25/96251.aspx

seems like no one likes to use ApplicationException.

If this is the feeling in general than why now just use

bool MyFunction(object sender, MyObject myObj){}

My point is that why even argument namespace anyways !

Thanks,
Po

[Kevin Spencer]

> This might sound little stupid to many but I was thinking that when we can

use object why we really need event args to pass in any functions e.g.
Some events don't require any additional information. Hence, the base class
for EventArgs has no properties. But some events can make use of lots of
information available to the sender. So, you can create inherited EventArgs
classes, and pass them, and the CLR has quite a few of them as well.

As for why EventArgs are sent when no information is needed, well, that's a
convention. You may or may not want to use it. Microsoft does, and they have
their reasons. It does create a uniformity in the coding, which is always a
good thing.
Maybe this question it is very much like my previous post on why we need 3
diff kind of exception when they not doing any good. Basically all are
System.Exception.
Even the type of an Exception class gives you some information about the
exception, like where it came from. Apparently, no other information is
needed.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Complex things are made up of
Lots of simple things.

"Pohihihi" <po******@hotmail.com> wrote in message
news:ui*************@TK2MSFTNGP15.phx.gbl... This might sound little stupid to many but I was thinking that when we can
use object why we really need event args to pass in any functions e.g.

bool MyFunction(object sender, System.EventArgs e){}

my question is targetted more on the customized event arguments that we
create while programming.
Is it just to make it more readable or maybe to make things in collective
and hierarchy?

Maybe this question it is very much like my previous post on why we need 3
diff kind of exception when they not doing any good. Basically all are
System.Exception.

System.Exception
System.SystemException
System.ApplicationException

And, if ApplicationException is there then what could have hurt adding
ConsoleException or WindowsApplicatoinException per say.

As per the following link (thanks to Jay Harlow)
http://blogs.msdn.com/brada/archive/.../25/96251.aspx

seems like no one likes to use ApplicationException.

If this is the feeling in general than why now just use

bool MyFunction(object sender, MyObject myObj){}

My point is that why even argument namespace anyways !

Thanks,
Po

[Jon Skeet [C# MVP]]

Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:

This might sound little stupid to many but I was thinking that when we can
use object why we really need event args to pass in any functions e.g.

Some events don't require any additional information. Hence, the base class
for EventArgs has no properties. But some events can make use of lots of
information available to the sender. So, you can create inherited EventArgs
classes, and pass them, and the CLR has quite a few of them as well.

As for why EventArgs are sent when no information is needed, well, that's a
convention. You may or may not want to use it. Microsoft does, and they have
their reasons. It does create a uniformity in the coding, which is always a
good thing.

I've never understood this argument in this case. If something doesn't
need any information, just don't provide an argument. We don't suggest
that people have an unnecessary argument for other method calls, so why
do it for event handling?

Conventions should always be questioned - the fact that the convention
comes from MS doesn't make it a good one.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Kevin Spencer]

> I've never understood this argument in this case. If something doesn't

need any information, just don't provide an argument. We don't suggest
that people have an unnecessary argument for other method calls, so why
do it for event handling?

Conventions should always be questioned - the fact that the convention
Heck, Jon, I wasn't advocating it. I specifically said that one could follow
it or not. By definition, a "convention" is not a requirement, but exists in
an organization to somehow enhance work flow (make it easier for one
developer to work with another's existing code), for the ease of use of the
software, or for extensibility/backwards compatibility. As for the Microsoft
convention of including an EventArgs in every event, I suspect some
combination of the latter 2 to be the case. That is, Microsoft programming
technologies are used all over the world by developers at every skill level.
Including the EventArgs in every event makes the event easier to understand
for beginning-level programmers, and aspiring programmers. And, in the case
of extensibility, and backwards compatibility, in the event that some class
or event is extended in such a way that at some future point it needs to
pass information through an EventArgs-derived class, the EventArgs class is
already there, and can be extended without breaking the object model.

These might seem to be trivial reasons for doing so, but they *are* reasons.
As I don't have to write software for the entire world to use, I can hardly
imagine the sort of issues they encounter, and can only guess at some of the
reasons for some of their in-house conventions. A lot of Microsoft's
in-house conventions have arisen in an effort to minimize support incidents,
which is one of the biggest expenditures they have. And money is certainly a
consideration when deciding upon the conventions a company employs. I
certainly don't follow *all* of them. But in our team, we do use a good
number of them, for the first reason I stated.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:

> This might sound little stupid to many but I was thinking that when we
> can
> use object why we really need event args to pass in any functions e.g.

Some events don't require any additional information. Hence, the base
class
for EventArgs has no properties. But some events can make use of lots of
information available to the sender. So, you can create inherited
EventArgs
classes, and pass them, and the CLR has quite a few of them as well.

As for why EventArgs are sent when no information is needed, well, that's
a
convention. You may or may not want to use it. Microsoft does, and they
have
their reasons. It does create a uniformity in the coding, which is always
a
good thing.

I've never understood this argument in this case. If something doesn't
need any information, just don't provide an argument. We don't suggest
that people have an unnecessary argument for other method calls, so why
do it for event handling?

Conventions should always be questioned - the fact that the convention
comes from MS doesn't make it a good one.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Pete Davis]

Jon,

Normally, I would agree with you, but in the case of events, I'm somewhat
torn.

Having the sender/eventargs thing with events does make it very easy to code
for events without having to know the specifics of the event.

On the other hand, with intellisense, this isn't quite the big deal it would
have been a few years back.

But if you look at it from the point of view of coding without intellisense,
I can code any event handler I want without knowing the specific arguments.
I can simply code it for an object and EventArgs and it will work (as all
EventArgs are derived from EventArgs, or should be).

But again, with intellisense, it doesn't really matter.

I certainly agree with the idea that just because it comes from MS doesn't
make it good. Don't even get me started on the qualms I have with their
implementation of a lot of things!!! I could go on for quite some time.

Pete

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:

> This might sound little stupid to many but I was thinking that when we
> can
> use object why we really need event args to pass in any functions e.g.

Some events don't require any additional information. Hence, the base
class
for EventArgs has no properties. But some events can make use of lots of
information available to the sender. So, you can create inherited
EventArgs
classes, and pass them, and the CLR has quite a few of them as well.

As for why EventArgs are sent when no information is needed, well, that's
a
convention. You may or may not want to use it. Microsoft does, and they
have
their reasons. It does create a uniformity in the coding, which is always
a
good thing.

I've never understood this argument in this case. If something doesn't
need any information, just don't provide an argument. We don't suggest
that people have an unnecessary argument for other method calls, so why
do it for event handling?

Conventions should always be questioned - the fact that the convention
comes from MS doesn't make it a good one.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Pohihihi]

Thank you every one for the thought. I get the idea that I am not alone in
thing the way I think and good thing is that there is always a different way
to see things, maybe better than mine or not do not matter but surely it is
there.

Thanks again.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:

> This might sound little stupid to many but I was thinking that when we
> can
> use object why we really need event args to pass in any functions e.g.

Some events don't require any additional information. Hence, the base
class
for EventArgs has no properties. But some events can make use of lots of
information available to the sender. So, you can create inherited
EventArgs
classes, and pass them, and the CLR has quite a few of them as well.

As for why EventArgs are sent when no information is needed, well, that's
a
convention. You may or may not want to use it. Microsoft does, and they
have
their reasons. It does create a uniformity in the coding, which is always
a
good thing.

I've never understood this argument in this case. If something doesn't
need any information, just don't provide an argument. We don't suggest
that people have an unnecessary argument for other method calls, so why
do it for event handling?

Conventions should always be questioned - the fact that the convention
comes from MS doesn't make it a good one.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Pete Davis <pdavis68@[nospam]hotmail.com> wrote:

Normally, I would agree with you, but in the case of events, I'm somewhat
torn.

Having the sender/eventargs thing with events does make it very easy to code
for events without having to know the specifics of the event.
How does it do that? You still need to know the exact signature,
otherwise you can't create the appropriate method - if the delegate
takes a MouseEventArgs, you can't just use EventArgs (at least in
v1.1).
On the other hand, with intellisense, this isn't quite the big deal it would
have been a few years back.

But if you look at it from the point of view of coding without intellisense,
I can code any event handler I want without knowing the specific arguments.
I can simply code it for an object and EventArgs and it will work (as all
EventArgs are derived from EventArgs, or should be).

No, that doesn't work. Try this:

using System;
using System.Windows.Forms;

public class Test
{
static void Main(string[] args)
{
MouseEventHandler handler = new MouseEventHandler(Foo);
}

static void Foo (object sender, EventArgs e)
{
}
}

With 1.1, it doesn't compile. I can't remember whether it would in 2.0
- I seem to remember that there's some covariance changes, but
unfortunately I'm between beta and release at the moment, with nothing
actually installed to try it out on...

Given the above, I can't see any benefit in telling people to use
EventArgs. The fact that it's a real class rather than an interface
makes it worse. Suppose I want to have some sort of ProcessStarted
event - the obvious parameter to pass would be a ProcessStartInfo, but
I can't (if I'm following conventions), because it doesn't derive from
EventArgs. (Admittedly even with an interface there'd be a problem here
because ProcessStartInfo is sealed, but apply the example with your own
classes and you'll see what I mean.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:

I've never understood this argument in this case. If something doesn't
need any information, just don't provide an argument. We don't suggest
that people have an unnecessary argument for other method calls, so why
do it for event handling?

Conventions should always be questioned - the fact that the convention
Heck, Jon, I wasn't advocating it. I specifically said that one could follow
it or not. By definition, a "convention" is not a requirement, but exists in
an organization to somehow enhance work flow (make it easier for one
developer to work with another's existing code), for the ease of use of the
software, or for extensibility/backwards compatibility. As for the Microsoft
convention of including an EventArgs in every event, I suspect some
combination of the latter 2 to be the case.

But I've never seen any real justification given - *how* does it do
either of these things? I don't see that it helps consistency in
reality.
That is, Microsoft programming
technologies are used all over the world by developers at every skill level.
Including the EventArgs in every event makes the event easier to understand
for beginning-level programmers, and aspiring programmers.
In what way? If no actual information is being passed, how is it easier
to understand the delegate definition when it contains an extra
parameter than when it doesn't?
And, in the case of extensibility, and backwards compatibility, in
the event that some class or event is extended in such a way that at
some future point it needs to pass information through an
EventArgs-derived class, the EventArgs class is already there, and
can be extended without breaking the object model.
If the event is changed to use a class derived from EventArgs, then
every handler which just takes EventArgs now breaks - at least in C#
1.1 - because a delegate can only be created with a method which takes
*exactly* those arguments.
These might seem to be trivial reasons for doing so, but they *are* reasons.
As I don't have to write software for the entire world to use, I can hardly
imagine the sort of issues they encounter, and can only guess at some of the
reasons for some of their in-house conventions. A lot of Microsoft's
in-house conventions have arisen in an effort to minimize support incidents,
which is one of the biggest expenditures they have. And money is certainly a
consideration when deciding upon the conventions a company employs. I
certainly don't follow *all* of them. But in our team, we do use a good
number of them, for the first reason I stated.

Where there's a good justification - or where it's entirely arbitrary,
and doesn't "cost" anything - I agree. In the case of EventArgs,
however, I can only see it as an entirely arbitrary constraint which
doesn't actually "buy" anything.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Kevin Spencer]

> If the event is changed to use a class derived from EventArgs, then

every handler which just takes EventArgs now breaks - at least in C#
1.1 - because a delegate can only be created with a method which takes
*exactly* those arguments.
Good point, Jon. I was not thhinking clearly about this issue.
Where there's a good justification - or where it's entirely arbitrary,
and doesn't "cost" anything - I agree. In the case of EventArgs,
however, I can only see it as an entirely arbitrary constraint which
doesn't actually "buy" anything.
My point was that just because one does not see something does not mean that
it does not exist. As a fellow Christian, I'm sure you can agree with that
statement.

Of course, I am not comparing Microsoft to God. What I *am* saying is that,
in the absence of fact, conclusions cannot be drawn with any confidence in
their correctness. Microsoft has been in the programming biz for over 30
years, and has learned a few lessons along the way. No doubt, they, like us,
have many more to learn. But if they have adopted a convention in-house, it
has been adopted with quite a bit of discussion, to which we were not privy.
We can't be aware of the nature of the conditions which led to the decision,
unless we ask Microsoft and receive a definitive response in return.

As a fellow MVP, I can assure you that I know as well as you do that
Microsoft is not always right. I have participated in critical discussions
of their software with them in which I was able to convince them that a
certain change was logical and/or necessary. I would expect you have too.
While we MVPs are generally Microsoft's strongest advocates, we can often be
some of their most ardent critics. This of course, stems from our desire to
see them continue to put out great software.

Still, from experience, I tend to begin with a presupposition that Microsoft
had a perfectly logical reason for doing something, and expect that if
wrong, someone may demonstrate to me that I am. In the gambling biz, this is
known as "playing the odds." Microsoft is *usually* right (these days
anyway) in the decisions they make. Therefore, if a presupposition is to be
made, I am more likely to be correct by presupposing that they were correct,
in the absense of fact.

If you *do* find out anything definitive, I would be as curious as you to
find out the facts. So, let us know!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
There's a seeker born every minute.
- Dr. "Happy" Harry Cox

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:

> I've never understood this argument in this case. If something doesn't
> need any information, just don't provide an argument. We don't suggest
> that people have an unnecessary argument for other method calls, so why
> do it for event handling?
>
> Conventions should always be questioned - the fact that the convention

Heck, Jon, I wasn't advocating it. I specifically said that one could
follow
it or not. By definition, a "convention" is not a requirement, but exists
in
an organization to somehow enhance work flow (make it easier for one
developer to work with another's existing code), for the ease of use of
the
software, or for extensibility/backwards compatibility. As for the
Microsoft
convention of including an EventArgs in every event, I suspect some
combination of the latter 2 to be the case.

But I've never seen any real justification given - *how* does it do
either of these things? I don't see that it helps consistency in
reality.

That is, Microsoft programming
technologies are used all over the world by developers at every skill
level.
Including the EventArgs in every event makes the event easier to
understand
for beginning-level programmers, and aspiring programmers.

In what way? If no actual information is being passed, how is it easier
to understand the delegate definition when it contains an extra
parameter than when it doesn't?

And, in the case of extensibility, and backwards compatibility, in
the event that some class or event is extended in such a way that at
some future point it needs to pass information through an
EventArgs-derived class, the EventArgs class is already there, and
can be extended without breaking the object model.

If the event is changed to use a class derived from EventArgs, then
every handler which just takes EventArgs now breaks - at least in C#
1.1 - because a delegate can only be created with a method which takes
*exactly* those arguments.

These might seem to be trivial reasons for doing so, but they *are*
reasons.
As I don't have to write software for the entire world to use, I can
hardly
imagine the sort of issues they encounter, and can only guess at some of
the
reasons for some of their in-house conventions. A lot of Microsoft's
in-house conventions have arisen in an effort to minimize support
incidents,
which is one of the biggest expenditures they have. And money is
certainly a
consideration when deciding upon the conventions a company employs. I
certainly don't follow *all* of them. But in our team, we do use a good
number of them, for the first reason I stated.

Where there's a good justification - or where it's entirely arbitrary,
and doesn't "cost" anything - I agree. In the case of EventArgs,
however, I can only see it as an entirely arbitrary constraint which
doesn't actually "buy" anything.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Kevin Spencer <ke***@DIESPAMMERSDIEtakempis.com> wrote:

If the event is changed to use a class derived from EventArgs, then
every handler which just takes EventArgs now breaks - at least in C#
1.1 - because a delegate can only be created with a method which takes
*exactly* those arguments.
Good point, Jon. I was not thhinking clearly about this issue.

It's quite possible Microsoft weren't either when they came up with the
convention.

Where there's a good justification - or where it's entirely arbitrary,
and doesn't "cost" anything - I agree. In the case of EventArgs,
however, I can only see it as an entirely arbitrary constraint which
doesn't actually "buy" anything.

My point was that just because one does not see something does not mean that
it does not exist. As a fellow Christian, I'm sure you can agree with that
statement.

Indeed. When it comes to conventions, however, I tend to rely on
reasoning rather than faith :)
Of course, I am not comparing Microsoft to God. What I *am* saying is that,
in the absence of fact, conclusions cannot be drawn with any confidence in
their correctness. Microsoft has been in the programming biz for over 30
years, and has learned a few lessons along the way. No doubt, they, like us,
have many more to learn. But if they have adopted a convention in-house, it
has been adopted with quite a bit of discussion, to which we were not privy.
We can't be aware of the nature of the conditions which led to the decision,
unless we ask Microsoft and receive a definitive response in return.

As a fellow MVP, I can assure you that I know as well as you do that
Microsoft is not always right. I have participated in critical discussions
of their software with them in which I was able to convince them that a
certain change was logical and/or necessary. I would expect you have too.
While we MVPs are generally Microsoft's strongest advocates, we can often be
some of their most ardent critics. This of course, stems from our desire to
see them continue to put out great software.
Sure.
Still, from experience, I tend to begin with a presupposition that Microsoft
had a perfectly logical reason for doing something, and expect that if
wrong, someone may demonstrate to me that I am. In the gambling biz, this is
known as "playing the odds." Microsoft is *usually* right (these days
anyway) in the decisions they make. Therefore, if a presupposition is to be
made, I am more likely to be correct by presupposing that they were correct,
in the absense of fact.
Thing is, it *sounds* like it's probably a good idea, until you look a
bit more closely. I've identified reasons you *wouldn't* want to do
this, but I still haven't heard any reasons why it's actually a good
idea. In the absence of any actual reasons in favour of the convention,
I'll continue to avoid it, personally.
If you *do* find out anything definitive, I would be as curious as you to
find out the facts. So, let us know!

I'll try to get a member of the C# team to answer... I'd be interested
to hear their reasons myself.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Truong Hong Thi]

As Microsoft thought that event arguments need a root base class, they
invented EventArgs. Thus, you could compare it with Exception instead
of ApplicationException. It would make sense to have all event args
inherited one base class (at least Microsoft thought so). Although
EventArgs contains no useful stuff its subclasses could inherit as
Exception does, it could provide Microsoft a place to put such thing in
case they might want all event args to have some property in common in
the future.

Regarding ApplicationException, its prolem is that you would never want
to catch it - which is the only reason whether a type of exception
should exist. Both exception handling and exception hierarchy are much
more complex than that of event args, so it cannot endure not-for-catch
exceptions.

Regards,
Thi

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:

<snip>

No, that doesn't work. Try this:

using System;
using System.Windows.Forms;

public class Test
{
static void Main(string[] args)
{
MouseEventHandler handler = new MouseEventHandler(Foo);
}

static void Foo (object sender, EventArgs e)
{
}
}

With 1.1, it doesn't compile. I can't remember whether it would in 2.0
- I seem to remember that there's some covariance changes, but
unfortunately I'm between beta and release at the moment, with nothing
actually installed to try it out on...

Just tried this with 2.0 and it *does* work due to delegate covariance
(or contravariance - I never get those two the right way round).

It seems odd to specify a convention which only becomes useful several
years later though!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Kevin Spencer]

> It seems odd to specify a convention which only becomes useful several

years later though!
Bill Gates once said he couldn't imagine a computer needing more than 640 KB
of memory. I suppose Microsoft has learned that lesson. In spades!

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jon Skeet [C# MVP] <sk***@pobox.com> wrote:

<snip>

No, that doesn't work. Try this:

using System;
using System.Windows.Forms;

public class Test
{
static void Main(string[] args)
{
MouseEventHandler handler = new MouseEventHandler(Foo);
}

static void Foo (object sender, EventArgs e)
{
}
}

With 1.1, it doesn't compile. I can't remember whether it would in 2.0
- I seem to remember that there's some covariance changes, but
unfortunately I'm between beta and release at the moment, with nothing
actually installed to try it out on...

Just tried this with 2.0 and it *does* work due to delegate covariance
(or contravariance - I never get those two the right way round).

It seems odd to specify a convention which only becomes useful several
years later though!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Krzysztof Cwalina]

Yes, Thi put it very nicely. It was done for future extensibility. I blogged
more about this at
http://blogs.msdn.com/kcwalina/archi...EventArgs.aspx. Hope
this helps.

Krzysztof Cwalina
Program manager, CLR
"Truong Hong Thi" wrote:

As Microsoft thought that event arguments need a root base class, they
invented EventArgs. Thus, you could compare it with Exception instead
of ApplicationException. It would make sense to have all event args
inherited one base class (at least Microsoft thought so). Although
EventArgs contains no useful stuff its subclasses could inherit as
Exception does, it could provide Microsoft a place to put such thing in
case they might want all event args to have some property in common in
the future.

Regarding ApplicationException, its prolem is that you would never want
to catch it - which is the only reason whether a type of exception
should exist. Both exception handling and exception hierarchy are much
more complex than that of event args, so it cannot endure not-for-catch
exceptions.

Regards,
Thi

[Jon Skeet [C# MVP]]

Krzysztof Cwalina <kcwalina@microsoft_dot_com> wrote:

Yes, Thi put it very nicely. It was done for future extensibility. I blogged
more about this at
http://blogs.msdn.com/kcwalina/archi...EventArgs.aspx. Hope
this helps.

Thanks very much - I'm glad I'm not just being silly thinking that
there haven't been any benefits *so far* :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too