«

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

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:15AA96D8-0108-4494-AB7C-...
> 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
>>
>

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

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:15AA96D8-0108-4494-AB7C-...
>> 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
>>>
>>
>
>

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:15AA96D8-0108-4494-AB7C-...
> 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
>>
>

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

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