By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,977 Members | 1,369 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,977 IT Pros & Developers. It's quick & easy.

Please Help! How to identify which button was clicked?

P: n/a
Hi all and thanks in advance,
I am stuck! I can't figure out how to identify which button was clicked on my ASP.NET page in the PostBack event? So what I am trying to do is to is to have an if statement like as follows in the PageLoad:

private void Page_Load(object sender, System.EventArgs e) {

if (!Page.IsPostBack) {

//do something here

} else {

if (btnSave.clicked)

//do something here

else

//do something else

}

I have my methods btnSave_Click and other buttons setup. It is just that when the buttons are clicked they still go through the Page load event and within the pageload event I need to differentiate which one of the buttons are clicked since it is essential to my code.

Am I crazy for wanting to do something like this? It was very easy to do before with ASP?

Thanks for your input!

Nov 18 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Amadelle wrote:
Hi all and thanks in advance,
I am stuck! I can't figure out how to identify which button was clicked
on my ASP.NET page in the PostBack event? So what I am trying to do is
to is to have an if statement like as follows in the PageLoad:
private void Page_Load(object sender, System.EventArgs e) {

if (!Page.IsPostBack) {

//do something here

} else {

if (btnSave.clicked)

//do something here

else

//do something else

}

I have my methods btnSave_Click and other buttons setup. It is just
that when the buttons are clicked they still go through the Page load
event and within the pageload event I need to differentiate which one of
the buttons are clicked since it is essential to my code.

Am I crazy for wanting to do something like this? It was very easy to
do before with ASP?

Thanks for your input!


I know there's a way to do this, not off-hand, but I am going to ask
'why?'? Since you have the events coded already, you'll know which
button when you get there (to one of them). Plus 'cancelling' the event
may be tough if that is something in mind (in Page_Load, if you want to
cancel or stop right there and redisplay).....

I'm curious as to why you're wanting to do this, if you can share...

--
Craig Deelsnyder
Microsoft MVP - ASP/ASP.NET
Nov 18 '05 #2

P: n/a
Amadelle,

If all of the buttons are of the same type then you can cast sender as the button directly like this:

Dim MyButton As Button = CType(sender, Button)

Then you can tell which button was clicked like this:

Select Case MyButton.ID
Case "MyButton1"
'---Do Something
Case "MyButton2"
'---Do Something Else
End Select

If you have different types of buttons you'll need to find out which type you're dealing with first before you may cast:

Select Case sender.GetType.ToString
Case "System.Web.UI.WebControls.ImageButton"
'---Cast to image button here
Case "System.Web.UI.WebControls.LinkButton"
'---Cast to link button here
End Select
--
Sincerely,

S. Justin Gengo, MCP
Web Developer / Programmer

www.aboutfortunate.com

"Out of chaos comes order."
Nietzsche
"Amadelle" <am******@yahoo.com> wrote in message news:O$**************@TK2MSFTNGP12.phx.gbl...
Hi all and thanks in advance,
I am stuck! I can't figure out how to identify which button was clicked on my ASP.NET page in the PostBack event? So what I am trying to do is to is to have an if statement like as follows in the PageLoad:

private void Page_Load(object sender, System.EventArgs e) {

if (!Page.IsPostBack) {

//do something here

} else {

if (btnSave.clicked)

//do something here

else

//do something else

}

I have my methods btnSave_Click and other buttons setup. It is just that when the buttons are clicked they still go through the Page load event and within the pageload event I need to differentiate which one of the buttons are clicked since it is essential to my code.

Am I crazy for wanting to do something like this? It was very easy to do before with ASP?

Thanks for your input!

Nov 18 '05 #3

P: n/a
"Amadelle" <am******@yahoo.com> wrote in message news:O$**************@TK2MSFTNGP12.phx.gbl...
Hi all and thanks in advance,
I am stuck! I can't figure out how to identify which button was clicked on my ASP.NET page in the PostBack event? So what I am trying to do is to is to have an if statement like as follows in the PageLoad:

The best solution I've found to this problem is to not do it.

Don't ask in Page_Load which control caused the PostBack. Instead, handle the postback event of each control:

private void btnSave_Click(object sender, EventArgs e)
{
// Action when Save clicked
}

private void btnCancel_Click(object sender, EventArgs e)
{
// Action when Cancel clicked
}
--
John Saunders
johnwsaundersiii at hotmail

Nov 18 '05 #4

P: n/a
I have come across this problem before. Sometimes you need to know before the event handler fires which button was clicked, particularly if you are creating dynamic controls or something that needs to be in page_load based on the button press.

The solution so far is to do a HttpContext.Current.Request[] of the buttons id. If the request comes back null, the button was not pressed. If the Request comes back with the ID of the button (essentially just a marker anyway) then it was that button that was pressed.

Example:
Page_Load:

// adding the button
Button oButton = new Button();
oButton.ID = "PRESSME1";
oCell.Controls.Add(oButton);
....
Somewhere else in PageLoad

....///testing for the button being pressed.
if (HttpContext.Current.Request["PRESSME1"] != null)
// the button was pressed. do something like add a dropdown list orsomething.
Another tricky one is trying to tell if a DropDownList or Checkbox marked as AutoPost has caused a postback without using event handlers. In this case you can use the JavaScript that .NET creates and hijack the "__event_target" form variable.
Do a request on the __EventTarget and whatever ID comes back is what caused the postback --- if the postback was caused by a DropDown or CheckBox or something that has AutoPost back. If a submit button caused the post back the __eventtarget is empty but you can do a request of the button's ID as described above.

Andrew S.
"John Saunders" wrote:
"Amadelle" <am******@yahoo.com> wrote in message news:O$**************@TK2MSFTNGP12.phx.gbl...
Hi all and thanks in advance,
I am stuck! I can't figure out how to identify which button was clicked on my ASP.NET page in the PostBack event? So what I am trying to do is to is to have an if statement like as follows in the PageLoad:

The best solution I've found to this problem is to not do it.

Don't ask in Page_Load which control caused the PostBack. Instead, handle the postback event of each control:

private void btnSave_Click(object sender, EventArgs e)
{
// Action when Save clicked
}

private void btnCancel_Click(object sender, EventArgs e)
{
// Action when Cancel clicked
}
--
John Saunders
johnwsaundersiii at hotmail

Nov 18 '05 #5

P: n/a
"Andy Z Smith" <An********@discussions.microsoft.com> wrote in message
news:A8**********************************@microsof t.com...
I have come across this problem before. Sometimes you need to know before the event handler fires which button was clicked, particularly if you are
creating dynamic controls or something that needs to be in page_load based
on the button press.
The solution so far is to do a HttpContext.Current.Request[] of the buttons id. If the request comes back null, the button was not pressed. If
the Request comes back with the ID of the button (essentially just a marker
anyway) then it was that button that was pressed.
Example:
Page_Load:

// adding the button
Button oButton = new Button();
oButton.ID = "PRESSME1";
oCell.Controls.Add(oButton);
...
Somewhere else in PageLoad

...///testing for the button being pressed.
if (HttpContext.Current.Request["PRESSME1"] != null)
// the button was pressed. do something like add a dropdown list orsomething.

Another tricky one is trying to tell if a DropDownList or Checkbox marked as AutoPost has caused a postback without using event handlers. In this
case you can use the JavaScript that .NET creates and hijack the
"__event_target" form variable. Do a request on the __EventTarget and whatever ID comes back is what caused the postback --- if the postback was caused by a DropDown or CheckBox
or something that has AutoPost back. If a submit button caused the post
back the __eventtarget is empty but you can do a request of the button's ID
as described above.

I've yet to find a situation where I've needed to know in Page_Load what
control posted back. It's always been possible to allow the postback events
and postback data events to fire and then to process the results of those
events in later handlers, like in the PreRender event. I have found this to
be true even for cases where the entire control hierarchy is created
dynamically.

Also, the techniques you mention are very dependant on the specific
implementation of the current version of ASP.NET. The two underscores in
"__EVENTTARGET" are an indicator that this is an internal,
implementation-dependant name, subject to change whenever they feel like it,
or just whenever they want to play with your mind...
--
John Saunders
johnwsaundersiii at hotmail
"John Saunders" wrote:
"Amadelle" <am******@yahoo.com> wrote in message news:O$**************@TK2MSFTNGP12.phx.gbl... Hi all and thanks in advance,
I am stuck! I can't figure out how to identify which button was clicked on my ASP.NET page in the PostBack event? So what I am trying to do
is to is to have an if statement like as follows in the PageLoad:
The best solution I've found to this problem is to not do it.

Don't ask in Page_Load which control caused the PostBack. Instead, handle the postback event of each control:
private void btnSave_Click(object sender, EventArgs e)
{
// Action when Save clicked
}

private void btnCancel_Click(object sender, EventArgs e)
{
// Action when Cancel clicked
}
--
John Saunders
johnwsaundersiii at hotmail

Nov 18 '05 #6

P: n/a
Agreed ... you should be able to do everything you need in the PreRender
handler. Use button click handlers to set page properties and/or
members, and process them on PreRender.

When I first begun .NET development, my initial instinct was to load
controls on page load as well, but that soon proved to be a pain. Since
then, I started using PreRender, and never looked back. Seems as though
you are spending the extra effort, going outside of the framework
provided, to achieve something you could have accomplished much faster
using the intrinsic event handlers and processing postback data on
Prerender.

ib.

John Saunders wrote:
"Andy Z Smith" <An********@discussions.microsoft.com> wrote in message
news:A8**********************************@microsof t.com...
I have come across this problem before. Sometimes you need to know before


the event handler fires which button was clicked, particularly if you are
creating dynamic controls or something that needs to be in page_load based
on the button press.
The solution so far is to do a HttpContext.Current.Request[] of the


buttons id. If the request comes back null, the button was not pressed. If
the Request comes back with the ID of the button (essentially just a marker
anyway) then it was that button that was pressed.
Example:
Page_Load:

// adding the button
Button oButton = new Button();
oButton.ID = "PRESSME1";
oCell.Controls.Add(oButton);
...
Somewhere else in PageLoad

...///testing for the button being pressed.
if (HttpContext.Current.Request["PRESSME1"] != null)
// the button was pressed. do something like add a dropdown list


orsomething.

Another tricky one is trying to tell if a DropDownList or Checkbox marked


as AutoPost has caused a postback without using event handlers. In this
case you can use the JavaScript that .NET creates and hijack the
"__event_target" form variable.
Do a request on the __EventTarget and whatever ID comes back is what


caused the postback --- if the postback was caused by a DropDown or CheckBox
or something that has AutoPost back. If a submit button caused the post
back the __eventtarget is empty but you can do a request of the button's ID
as described above.

I've yet to find a situation where I've needed to know in Page_Load what
control posted back. It's always been possible to allow the postback events
and postback data events to fire and then to process the results of those
events in later handlers, like in the PreRender event. I have found this to
be true even for cases where the entire control hierarchy is created
dynamically.

Also, the techniques you mention are very dependant on the specific
implementation of the current version of ASP.NET. The two underscores in
"__EVENTTARGET" are an indicator that this is an internal,
implementation-dependant name, subject to change whenever they feel like it,
or just whenever they want to play with your mind...

Nov 18 '05 #7

P: 1
Whereas I agree that __EVENTTARGET is subject to change in later versions, I disagree that the _need_ to know what triggered a PostBack doesn't exist.

On a complex form, you've got to worry about stuff like that. Take the following situation: you've got a checkbox and a button in a repeater. The CheckBox can only AutoPostBack. It can not generage the repeater_ItemCommand event. On the other hand, the button fires the ItemCommand event.

Therefore, if you set up a handler for the checkbox autopostback, when you click the button that handler will also get called. If your button relies on state that the checkbox handler changes, then you've got an inconsistent state by the time the ItemCommand event gets triggered.

Therefore, the Request[buttonId] method is very good at figuring out what's going on before processing things in PageLoad. However, say button1 is your Button object, you have to use Request[button1.UniqueID] instead of Request[button1.ID] or Request[button1.ClientID]. Use UniqueID because this is what gets registered to the Request object if the button1 object is nested inside repeaters or other parent objects on your form.
Apr 21 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.