Significance of System.EventArgs?

[Paul Mc]

G'day all.

I am curious about the significance of the System.EventArgs object typically
passed into control events...

In the doco, it states that the EventArgs class has one field, Empty, which
"Represents an event with no state.". It further states that this "allows
for the efficient use of events with no state, as it can be raised efficiently."

Now I obviously do not understand the significance of this parameter. Why
is it there? If it just represents a stateless event, as seems to be implied
in the doco, why pass it at all - wouldn't simply having no parameter at
all be more efficient?

Or is it there due to the implementation of some interface?

Any information on this would really be appreciated - to satisfy my curiosity
if nothing else! "8-)
Cheers,
Paul

[Jonathan Allen]

> If it just represents a stateless event, as seems to be implied
> in the doco, why pass it at all - wouldn't simply having no parameter at
> all be more efficient?

The main reason would be for consistency. By making all events use the same
signature, you can create generic handlers. It also allows for future
expansion. Just because the event doesn't have any parameters now shouldn't
prevent you from adding them later.

As to the reason you don't just pass Nothing, I have no idea.

--
Jonathan Allen


"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3af73ff9$1@news.devx.com...
>
> G'day all.
>
> I am curious about the significance of the System.EventArgs object
typically
> passed into control events...
>
> In the doco, it states that the EventArgs class has one field, Empty,
which
> "Represents an event with no state.". It further states that this "allows
> for the efficient use of events with no state, as it can be raised
efficiently."
>
> Now I obviously do not understand the significance of this parameter. Why
> is it there? If it just represents a stateless event, as seems to be
implied
> in the doco, why pass it at all - wouldn't simply having no parameter at
> all be more efficient?
>
> Or is it there due to the implementation of some interface?
>
> Any information on this would really be appreciated - to satisfy my
curiosity
> if nothing else! "8-)
> Cheers,
> Paul
>

[Gregor R. Peisker]

Hi Paul,

> I am curious about the significance of the System.EventArgs object typically
> passed into control events...
>
> In the doco, it states that the EventArgs class has one field, Empty, which
> "Represents an event with no state.". It further states that this "allows
> for the efficient use of events with no state, as it can be raised efficiently."

The empty field typically returns an object that isn't initialized (apart from default
init values) - you'll find it in many structures and classes (just type "Empty field"
into the help index). These fields can be used to test whether something is
initialized, or to conveniently have an object with the default values set, for
example.

Note that the Empty field is a Shared (static in C#) member, so it isn't passed with the
EventArgs instance. However, you can use this field when you raise an event with no
parameters:

RaiseEvent HellFreeze(Me, EventArgs.Empty)

So the purpose is convenience. Without the empty field, you have to create an instance
with "New".

> Now I obviously do not understand the significance of this parameter. Why
> is it there? If it just represents a stateless event, as seems to be implied
> in the doco, why pass it at all - wouldn't simply having no parameter at
> all be more efficient?

The term "stateless" is somewhat overloaded, IMO :-). I assume you mean events that don't
pass parameters?

Event handlers that have the same signatures can be used to sink different events. Every
event handler in the .NET framework has a sender parameter, and a reference to an instance
of either EventArgs or a class derived from it. Of course, for the handler signature to
match, the argument types must be exactly the same. Still, the EventArgs class allows for
some "customization" by providing the ExtendedInfo property (which returns an Object).

I think the goal of mapping handlers to events in a flexible manner is a worthy one. But
it implies having some event signature convention, even if you don't intend to pass any
arguments. The Empty will addresses this problem, to some extent. Also, as the EventArgs
arguement is of a reference type, it's easy to pass data back to the caller (for example,
in cancellable events).

Regards,
Gregor

[Paul Mc]

G'Day Gregor. Thanks for the response.

>Event handlers that have the same signatures can be used to sink different
events. Every
>event handler in the .NET framework has a sender parameter, and a reference
to an instance
>of either EventArgs or a class derived from it. Of course, for the handler
signature to
>match, the argument types must be exactly the same.

OK, makes sense. So it is basically Implementing a common "Event Signature"
interface, thus allowing us to expose many events to a single handler.

>Still, the EventArgs class allows for
>some "customization" by providing the ExtendedInfo property (which returns
an Object).
<Snip>
>Also, as the EventArgs
>arguement is of a reference type, it's easy to pass data back to the caller
(for example,
>in cancellable events).

I will obviously want to get a good handle on this. Would you consider it
to be good practice to raise events from my own objects with this signature?

Cheers,
Paul

[Gregor R. Peisker]

Hi Paul,

> >Still, the EventArgs class allows for
> >some "customization" by providing the ExtendedInfo property (which returns
> an Object).
> <Snip>
> >Also, as the EventArgs
> >arguement is of a reference type, it's easy to pass data back to the caller
> (for example, in cancellable events).
>
> I will obviously want to get a good handle on this. Would you consider it
> to be good practice to raise events from my own objects with this signature?

Yes. The EventHandler delegate ("sender As Object, e As EventArgs") is the most common
signature. But there is also a CancelEventHandler delegate, a MouseEventHandler, and maybe
there are other generic event handlers. So there are some conventions to build on already.
Also, I see events as "anomymous" callbacks, convienient notifactions, if you will,
conceptually, so it makes sense to let the event listener decide which sort of handlers to
use; that is, use standard signatures.

Here's how I understand the event signature pattern:

In classic VB, there was no need for the "sender" argument, because event sinking require
a WithEvents reference at the class level anyway. But in VB.NET, events can be mapped to
handlers dynamically; so it's good to have this information.

Then, there's the EventArgs argument. It's just one object that's passed, so it's possible
to pass more information in future versions just by adding properties to the event args
class without breaking compatibility - like a third mouse coordinate :-)

Regards,
Gregor

[Franklin E. Vargas]

Greetings!

I spent enough time yesterday thinking about your EventArgs questions to
become curious about that issue myself. Finally, I decided to start "cheating"
and conduct some investigation. Here is what transpired.

1. Following plenty of speculation, I opened "mscorlib.dll" using the Intermediate
Language (IL) Disassembler tool that comes with the Framework Beta 1. This
unveiled the insides of the System.EventArgs class and its workings. Here
is a VB.NETish class description of EventArgs.

Public Class EventArgs
' This is how I visualize the Empty declaration and instantiation.
' Notice that Empty is instantiated without arguments.
' Naturally this field is a singleton like String.Empty
Shared Public ReadOnly Empty as EventArgs = new EventArgs()

Overloads Sub New()
' The object instance constructor
' Simply invokes the overloaded constructor with the argument.
Return Me.New(Nothing)
End Sub

Overloads Sub New(extendedInfo as System.Object)
' Calls the System.Object constructor.
MyBase.New

m_extendedInfo = ExtendedInfo
End Sub

Public Function get_ExtendedInfo() As System.Object
' This function is not documented in the framework.
Return m_extendedInfo
End Function

ReadOnly Property ExtendedInfo As Object
' The System is somehow notified that this is an absolete attribute.
' The "ExtendedInfo is obsolete and is being removed in Beta 2..."
is given.
' This property is not documented in the framework.
Get
return get_ExtendedInfo()
End Get
End Property

' This is a local reference to the extended information.
Private m_extendedInfo As System.Object
End Class

2. The EventArgs.Empty field and the ExtendedInfo object passed to the constructor
are really unrelated. Because EventArgs is a sub-class of Object, it must
maintain this extended object reference in its own private memory and there
must be ways for the CLR to obtain this information back. In the case of
the Empty EventArgs, that extended information is 'Nothing'.
3. There are two possible interpretations of the questions asked about EventArgs.
Are we inquiring about the purpose of special EventArgs.Empty event arguments
or about the function of the EventArgs.m_ExtendedInfo object reference.
4. I have conducted a rough search of the libraries for "ExtendedInfo" and
found only one (1) place where the get_ExtendedInfo() function is invoked.
It is called from the Microsoft.JScript.VsaReference. OnTypeResolve(sender
as Object, e a System.EventArgs) handler. This handler appears to be associated
with the compilation of Java Scripts. Unfortunately, this entire module
is not documented in the SDK Docs. If I were to guess, VSA may possibly
stand for Visual Studio Analyzer. In any case, I think this is probably
a trivial use of the Extended Info.
5. I also found one (1) place in MSDN on-line with "ExtendedInfo". The application
is "Web Pages | ViewExpenses.aspx". In this example, ExtendedInfo is used
to pass the index or unique identifier on an item on a list via an "_OnClick"
event. I have not determined that this module must really use ExtendedInfo.
6. When EventArgs and sub-classes of it are passed to the event handling
functions, the event handling mechanism does not manipulate the EventArgs
in any way. Therefore, m_ExtendedInfo is not inspected nor adjusted by the
mechanism. I checked this in Delegate, MultiCast Delegate and Event Handler.
7. The .NET Framework SDK Documentation has no reference to the get_ExtendedInfo
function. It has multiple references to Empty.
8. MSDN on-line also revealed the Event.Event class from the Windows Foundation
Classes for Java. Here is the description of that class.

"The Event class is typically used for events that have no associated information.
The EMPTY field is used to represent such "empty" events. (The Event class
also defines the extendedInfo field, which holds specialized information
only for com.ms.wfc.html events. This field is not used outside the context
of the com.ms.wfc.html package.)"

Aha! May this be the culprit? Well, I have flipped briefly through pages
of "Postback Data Processing" hoping to find some uses there. However, the
places where I found Event.extendedInfo simply reveal that most anything
that can be done with extendedInfo has been duplicated in plain parameters
in the .NET.
9. In some cases such as Reflections, parameters are eventually represented
as an array of objects when they reach the event.

The question as to the function of the Empty field is different from that
of the ExtendedInfo private object. Insterestingly, VB.NET has determined
that we don't need "empty" nor "null". "Nothing" is sufficient. However,
from a practical perspective, it is sometimes more efficient to treat "Nothing"
as if it were something. If a function is expecting something and is given
"Nothing" then to work properly, this function would have to check for "Nothing".
To avoid ah-hoc polymorphism nightmares there are distinctions between "Nothing"
(the empty set), and an object containing "Nothing."

Although this discussion is not restricted to EventArgs, here are some differences
between Nothing and EventArgs.Empty:
Nothing.get_ExtendedInfo() should raise an exception.
EventArgs.Empty.get_ExtendedInfo() should return Nothing.

There exists only one Nothing in the entire application.
Although this should be likewise for Empty, we could potentially create
an instance of EventArgs that mimics Empty. This can be seen as a good thing
because it means we can clone Empty. Making Empty shared is an effort to
make it a singleton.

The possible consequences of using Nothing in place of Empty is that this
requires that the target function, depending on how it uses EventArgs, must
check for Nothing prior to using the EventArgs.

Finally, you may think of concrete sub-classes EventArgs representing a set
of parameters plus and some extended information. Also, there exists a special
set called EventArgs.Empty consisting of the empty set of parameters and
the empty set of extended information (represented by Nothing).

-----------------------------------------------------------

"Jonathan Allen" <greywolf@cts.com> wrote:
>> If it just represents a stateless event, as seems to be implied
>> in the doco, why pass it at all - wouldn't simply having no parameter
at
>> all be more efficient?
>
>The main reason would be for consistency. By making all events use the same
>signature, you can create generic handlers. It also allows for future
>expansion. Just because the event doesn't have any parameters now shouldn't
>prevent you from adding them later.
>
>As to the reason you don't just pass Nothing, I have no idea.
>
>--
>Jonathan Allen
>
>
>"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
>news:3af73ff9$1@news.devx.com...
>>
>> G'day all.
>>
>> I am curious about the significance of the System.EventArgs object
>typically
>> passed into control events...
>>
>> In the doco, it states that the EventArgs class has one field, Empty,
>which
>> "Represents an event with no state.". It further states that this "allows
>> for the efficient use of events with no state, as it can be raised
>efficiently."
>>
>> Now I obviously do not understand the significance of this parameter.
Why
>> is it there? If it just represents a stateless event, as seems to be
>implied
>> in the doco, why pass it at all - wouldn't simply having no parameter
at
>> all be more efficient?
>>
>> Or is it there due to the implementation of some interface?
>>
>> Any information on this would really be appreciated - to satisfy my
>curiosity
>> if nothing else! "8-)
>> Cheers,
>> Paul
>>
>
>