How to determine control that fired event

Discussion in 'ASP .Net' started by milop, Apr 3, 2009.

  1. milop

    milop Guest

    Hello.

    Using .Net 2.0 and above, how,in the Page_Load event, can I determine what
    control triggered the postback?

    Thanks in advance,

    Mike
     
    milop, Apr 3, 2009
    #1
    1. Advertising

  2. You could use the sender parameter to get who fired the trigger.
    Its a object so you need a cast.






    "Patrice" <http://www.chez.com/scribe/> escreveu na mensagem
    news:...
    > You could use the hidden __EVENTARGET form field if you really need to
    > knwo that in the Load event. Usually you do that in the corresponding
    > event handler for this control.
    >
    > --
    > Patrice
    >
    > "milop" <> a écrit dans le message de groupe de
    > discussion : ...
    >> Hello.
    >>
    >> Using .Net 2.0 and above, how,in the Page_Load event, can I determine
    >> what control triggered the postback?
    >>
    >> Thanks in advance,
    >>
    >> Mike
    >>

    >
     
    Rafael Malheiros, Apr 3, 2009
    #2
    1. Advertising

  3. milop

    milop Guest

    Hi, Mark. Thanks for the response.

    That I know and employ all of it.

    Page_Load usually has code to restore state and application data (like
    customer information which involves one or more DB round trips), restoring
    user controls, etc. There are situations where I do not want such code to
    execute when certain controls are clicked because it would be wasteful.

    I have modularized functionality into functions and subs and call them in
    certain controls' events, but I am looking for a different approach.

    Thanks again,

    Mike

    "Mark Rae [MVP]" <> wrote in message
    news:%...
    > "milop" <> wrote in message
    > news:...
    >
    >> Using .Net 2.0 and above, how,in the Page_Load event, can I determine
    >> what control triggered the postback?

    >
    > As Patrice said, you can inspect the __EVENTARGET form field.
    >
    > However, you should really think carefully about why you think you need to
    > know this in the Page_Load event...
    >
    > E.g. if you have an asp:Button webcontrol, when you click it it will cause
    > a postback and then its Click event will fire - this is where you will
    > write anything which needs to happen when this button is clicked, and the
    > Page_Load event should never need to know about it specifically.
    >
    > Alternatively, if e.g. you had ten asp:Button webcontrols all of which did
    > almost the same thing, then you would wire them all up to use the same
    > server-side event, maybe a Command event, and then set a value in each
    > webcontrols CommandArgument property which could be inspected server-side
    > in order to branch the code as required...
    >
    >
    > --
    > Mark Rae
    > ASP.NET MVP
    > http://www.markrae.net
     
    milop, Apr 3, 2009
    #3
  4. milop

    milop Guest

    Hi Rafael. Thanks for the response.

    I found this approach not to be straight forward.

    Thanks,

    Mike

    "Rafael Malheiros" <> wrote in message
    news:%...
    > You could use the sender parameter to get who fired the trigger.
    > Its a object so you need a cast.
    >
    >
    >
    >
    >
    >
    > "Patrice" <http://www.chez.com/scribe/> escreveu na mensagem
    > news:...
    >> You could use the hidden __EVENTARGET form field if you really need to
    >> knwo that in the Load event. Usually you do that in the corresponding
    >> event handler for this control.
    >>
    >> --
    >> Patrice
    >>
    >> "milop" <> a écrit dans le message de groupe de
    >> discussion : ...
    >>> Hello.
    >>>
    >>> Using .Net 2.0 and above, how,in the Page_Load event, can I determine
    >>> what control triggered the postback?
    >>>
    >>> Thanks in advance,
    >>>
    >>> Mike
    >>>

    >>

    >
    >
     
    milop, Apr 3, 2009
    #4
  5. milop

    milop Guest

    Hi, Patrice. Thanks for responding.

    I don't know why I never thought of that.

    Thank you,

    Mike

    "Patrice" <http://www.chez.com/scribe/> wrote in message
    news:...
    > You could use the hidden __EVENTARGET form field if you really need to
    > knwo that in the Load event. Usually you do that in the corresponding
    > event handler for this control.
    >
    > --
    > Patrice
    >
    > "milop" <> a écrit dans le message de groupe de
    > discussion : ...
    >> Hello.
    >>
    >> Using .Net 2.0 and above, how,in the Page_Load event, can I determine
    >> what control triggered the postback?
    >>
    >> Thanks in advance,
    >>
    >> Mike
    >>

    >
     
    milop, Apr 3, 2009
    #5
  6. Mike, if I could toss in my $.02?

    > Page_Load usually has code to restore state and application data (like
    > customer information which involves one or more DB round trips), restoring
    > user controls, etc. There are situations where I do not want such code to
    > execute when certain controls are clicked because it would be wasteful.


    I had a project a little while back where I had some of the same desires.
    Why hit the database every time the page does a postback, why display
    controls or sections of the page if they aren't needed, etc.

    What we ended up doing was on the first time the page loaded we'd hit the
    database, do the logic processing, what have you, and then store all that in
    a calss object, and save that object as a Session variable. Then, when the
    page would postback from a user input or whatever, we could then restore the
    object from the Session, check the properties of the object which designated
    how the page should be set up or provide data for items to be bound to, and
    so forth. This was all done inside the Page_Init so that by the time the
    Page_Load event fired, only the items needed would be processed and sent
    back to the user.

    We cut load times, processing, and such down to a fraction of the time it
    used to take, and also made future expansion, maintenance, and debugging a
    breeze.

    I know this doesn't answer the question of your original post, and not sure
    if this would help you out, but thought I would toss it out there for your
    consideration.

    -- Andrew
     
    Andrew Raastad, Apr 3, 2009
    #6
  7. > "Mark Rae [MVP]" <> wrote in message
    > news:OnUck%...
    > That's fine for a very small number of concurrent users, but is completely
    > non-scalable.
    >
    > Imagine, say, 500 concurrent users and you will could potentially have 500
    > copies of the page's state stored in Session memory...


    You bring up a good point, scalability should always be something that is
    considered.... depending on the application being written and where used.
    My suggestion was to keep in memory a copy of an object that could contain
    datatables/datasets, various strings, longs, or other items as properties,
    and who knows what else as it would depend on the need of the application.
    So true, you could in effect have a single copy of the object in memory
    taking anywhere from just a few KB to a few hundred. But what I would argue
    is that even at a couple hundred KB per copy, the environment where massive
    numbers of concurrent users would be encountered would dictate this
    application be placed on a true server, and today's servers have many (if
    not dozens) of GB's of memory. That coupled with effective and efficient
    code to destroy objects no longer in use, garbage collection, and other
    methods, make using the Session area for storage and retrieval of items as I
    mentioned a highly valuable and accessible resource and tool to be
    exploited.

    You shouldn't be so quick to toss out the "scalability" buzz word and then
    summarily dismiss the idea proposed. Mike has not mentioned what
    environment this application of his will be run from (Intranet, Internet,
    user population, etc.), nor do we know if my suggestion would be utilized in
    just a segment of the overall application or be used throughout. If this
    process were placed on a public page of a public web site, then yes, there
    could potentially be thousands of concurrent sessions... but if this process
    Mike's building is on a single page within the admin section of an Intranet
    website, there may be less than half a dozen in memory at any given time.

    I think it highly unfair of you to so readily judge a suggestion, and
    attempt to bias the OP against it just as quickly, without knowing or
    further discussing facts surrounding its possible implementation. That and
    your "but is completely non-scalable" comment is in fact very false.

    -- Andrew

    Oh, btw, I was *not* suggesting keeping a copy of the state of the entire
    page in memory (that's called ViewState)... I was suggesting having an
    object that would have various properties whose values could be used to
    designate if controls should be displayed or not, contain a datatable or
    dataset that a ListView or GridView could be re-bound to avoiding a trip
    back to the database, and other informational items as needed the page could
    then access to help decide the state of the controls and such displayed on
    the page.
     
    Andrew Raastad, Apr 3, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. cheung
    Replies:
    2
    Views:
    605
    Justin Bartels
    Oct 20, 2003
  2. jorge
    Replies:
    2
    Views:
    1,341
    jorge
    May 26, 2004
  3. Jeff User
    Replies:
    6
    Views:
    4,797
    Jeff User
    Nov 28, 2005
  4. Replies:
    2
    Views:
    483
    Mark Rae
    Jun 19, 2006
  5. Fabrizio
    Replies:
    5
    Views:
    261
    Alessandro Zifiglio
    Feb 24, 2004
Loading...

Share This Page