Significance of System.EventArgs?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 6 of 6

Thread: Significance of System.EventArgs?

  1. #1
    Paul Mc Guest

    Significance of System.EventArgs?


    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


  2. #2
    Jonathan Allen Guest

    Re: Significance of System.EventArgs?

    > 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
    >




  3. #3
    Gregor R. Peisker Guest

    Re: Significance of System.EventArgs?

    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










  4. #4
    Paul Mc Guest

    Re: Significance of System.EventArgs?


    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


  5. #5
    Gregor R. Peisker Guest

    Re: Significance of System.EventArgs?

    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



  6. #6
    Franklin E. Vargas Guest

    Re: Significance of System.EventArgs?


    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
    >>

    >
    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center