Adam <adam2001usa@ho tmail.com> wrote:[color=blue]
> What is the advantage of using a custom eventargs in an event versus
> just defining the delegate with data parameters?[/color]
Not a lot, IMO. It's one of the few MS conventions which I think is
less than useful. Make the delegate take exactly the right parameters,
and just use it :)
I think the idea is to help establish a pattern which is easily modified
if there is a change in the signature/event. If you just pass all the
parameters, it can become unwieldy, and you might not always have access to
the sender of the event (which the current pattern demands).
"Adam" <adam2001usa@ho tmail.com> wrote in message
news:1118347321 .666943.293860@ z14g2000cwz.goo glegroups.com.. .[color=blue]
> What is the advantage of using a custom eventargs in an event versus
> just defining the delegate with data parameters?
>
> Thanks in advance.
>
> Adam
>[/color]
Nicholas Paldino [.NET/C# MVP] <mvp@spam.guard .caspershouse.c om> wrote:[color=blue]
> I think the idea is to help establish a pattern which is easily modified
> if there is a change in the signature/event. If you just pass all the
> parameters, it can become unwieldy, and you might not always have access to
> the sender of the event (which the current pattern demands).[/color]
But if the sender of the event isn't useful for the particular event, I
wouldn't bother including it. It's like not including the caller on a
parameter call - occasionally you need it, but often you don't. For GUI
work it can often be useful to know what raised the event, but if
that's the case in this situation, there's nothing to stop you from
including the sender as a parameter if you want to.
Basically, you can design the delegate around how you want to use it -
if the MS conventions don't fit with that, I wouldn't lose sleep over
breaking them in this situation.
Nicholas Paldino [.NET/C# MVP] <mvp@spam.guard .caspershouse.c om> wrote:[color=blue]
> I think the idea is to help establish a pattern which is easily modified
> if there is a change in the signature/event. If you just pass all the
> parameters, it can become unwieldy, and you might not always have access to
> the sender of the event (which the current pattern demands).[/color]
But if the sender of the event isn't useful for the particular event, I
wouldn't bother including it. It's like not including the caller on a
parameter call - occasionally you need it, but often you don't. For GUI
work it can often be useful to know what raised the event, but if
that's the case in this situation, there's nothing to stop you from
including the sender as a parameter if you want to.
Basically, you can design the delegate around how you want to use it -
if the MS conventions don't fit with that, I wouldn't lose sleep over
breaking them in this situation.
Comment