about event handlers

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Tony

    about event handlers

    Hello!

    Is it the normal procedure in C# and .NET framework to always use the actual
    event object which is
    passed as the second parameters to the event handler.

    All of them are derived from the base class which is EventArgs so because of
    this the second parameters could in all cases be EventArgs which had be be
    cased
    in the most cases to the the actual referenced event argument object before
    accessing the referenced object.

    Here I have some examples
    private void textBoxAge_KeyP ress(object sender, KeyPressEventAr gs e)
    private void textBoxAge_Vali dating(object sender, CancelEventArgs e)
    private void textBox_TextCha nged(object sender, EventArgs e)

    //Tony


  • Peter Duniho

    #2
    Re: about event handlers

    On Tue, 24 Jun 2008 23:51:03 -0700, Tony <johansson.ande rsson@telia.com >
    wrote:
    Is it the normal procedure in C# and .NET framework to always use the
    actual
    event object which is
    passed as the second parameters to the event handler.
    >
    All of them are derived from the base class which is EventArgs so
    because of
    this the second parameters could in all cases be EventArgs which had be
    be
    cased
    in the most cases to the the actual referenced event argument object
    before
    accessing the referenced object.
    Typos notwithstanding , you've answered your own question. :)

    Most of the time, you want the data that's in that EventArgs sub-class.
    It wouldn't make any sense to declare your event handler method to take
    EventArgs instead, only to have to cast it before you use it.

    So, yes...I feel it's "the normal procedure" to always use the actual
    type, rather than the base type.

    I suppose that for an event handler where you're going to ignore that
    parameter, you could declare the argument as just the base class. In
    fact, that might help document the fact that the handler method is
    ignoring the parameter. But in that scenario, you might want to ask
    yourself why it is you're handling the event in the first place. :)
    (That's for events that actually do sub-class the EventArgs; obviously for
    events that don't, you'd use EventArgs and that'd be perfectly normal).

    Pete

    Comment

    • Tony

      #3
      Re: about event handlers

      Hello!

      One more thing assume I create an event and an object derived from the
      eventArgs containing some info about the
      event.
      Then create another event also with an object derived from the eventArgs
      containing some info about the
      event.

      When creating the event handler I have two choices either use EventArgs as
      the second parametr and cast to the actual type
      or
      use two separate event handler with the actual type as the second paramer.

      So does it exist some recommended guidline to which one to use.
      I would say use different event handler unles they they are logically
      connected in some way.

      Give me some comment about which one to use according to OOP.

      //Tony

      "Peter Duniho" <NpOeStPeAdM@nn owslpianmk.coms krev i meddelandet
      news:op.udalccb s8jd0ej@petes-computer.local. ..
      On Tue, 24 Jun 2008 23:51:03 -0700, Tony <johansson.ande rsson@telia.com >
      wrote:
      >
      Is it the normal procedure in C# and .NET framework to always use the
      actual
      event object which is
      passed as the second parameters to the event handler.

      All of them are derived from the base class which is EventArgs so
      because of
      this the second parameters could in all cases be EventArgs which had be
      be
      cased
      in the most cases to the the actual referenced event argument object
      before
      accessing the referenced object.
      >
      Typos notwithstanding , you've answered your own question. :)
      >
      Most of the time, you want the data that's in that EventArgs sub-class.
      It wouldn't make any sense to declare your event handler method to take
      EventArgs instead, only to have to cast it before you use it.
      >
      So, yes...I feel it's "the normal procedure" to always use the actual
      type, rather than the base type.
      >
      I suppose that for an event handler where you're going to ignore that
      parameter, you could declare the argument as just the base class. In
      fact, that might help document the fact that the handler method is
      ignoring the parameter. But in that scenario, you might want to ask
      yourself why it is you're handling the event in the first place. :)
      (That's for events that actually do sub-class the EventArgs; obviously for
      events that don't, you'd use EventArgs and that'd be perfectly normal).
      >
      Pete

      Comment

      • Peter Duniho

        #4
        Re: about event handlers

        On Wed, 25 Jun 2008 00:34:36 -0700, Tony <johansson.ande rsson@telia.com >
        wrote:
        One more thing assume I create an event and an object derived from the
        eventArgs containing some info about the event.
        Then create another event also with an object derived from the eventArgs
        containing some info about the event.
        >
        When creating the event handler I have two choices either use EventArgs
        as
        the second parametr and cast to the actual type or
        use two separate event handler with the actual type as the second
        paramer.
        If the processing of the event is so similar as to justify using the same
        handler method for both, then the event should almost certainly be using
        the same EventArgs sub-class.
        So does it exist some recommended guidline to which one to use.
        I would say use different event handler unles they they are logically
        connected in some way.
        Yes, I try not to reuse the same method for operations that are _not_
        logically connected in some way. :)

        (In fact, as I've noted many times before in this newsgroup, I don't even
        like having one method doing two disparate things even if those two things
        do in fact happen to be related to each other in some logical way...see my
        repeated objections to MSDN's approach to methods using Invoke() and
        InvokeRequired, for example).

        Pete

        Comment

        Working...