On Mon, 26 May 2008 05:54:57 -0700, Andrus <ko********@hot.eewrote:
Where to find link to this standard ?
http://msdn.microsoft.com/en-us/library/ms229011.aspx
I havent seen any reference to it.
There is a prominent link to the above page from the main "Events (C#
Programming Guide)" page.
Why this standard exists ? I must use ugly casts due to this.
"Ugly" is in the eye of the beholder. Also, I doubt anyone here can tell
you precisely why the standard exists. But we can offer some possible
benefits as suggestions for why it might be that way:
* Avoids type proliferation. There's a delegate type for every event
signature. We already have a different delegate type for every different
event data argument type (EventArgs-derived classes). You can imagine the
number of types that would be required to support every combination of
possible sender and event data arguments.
* Typing the sender more narrowly than Object doesn't necessarily
remove the need to cast anyway. In the Forms namespace, for example, it's
not uncommon to have a single handler deal with events from multiple
objects of different types. Inasmuch as you need the actual type of the
sender (not always the case, but does happen), you'd wind up casting from
the given type anyway (if a "lowest-common-denominator" type was used,
like Control), or you would not be able to easily use the same handler
with multiple events (if the event was always declared to match the actual
type of the sender).
There may be other reasons, but IMHO the first of the above is quite
significant, and the second of the above effectively minimizes your claim
that one could avoid "ugly casts" in a practical way without sacrificing
existing benefits.
I'm planning to create my own event which are set by DataGridView if
entity property is changed and committed.
Is it OK to create event wothout sender and passing aruments as
parameters, without using EventArgs class ?
It depends on how you're going to use it. But yes, assuming your code is
the only code that will ever use the event, you can make it look any way
you like. Some binding mechanisms rely on your code following the .NET
convention, so if you care about your event and associated property being
useful in a binding scenario (not uncommon for a "property changed"
event), you should follow the .NET design standard.
Pete