views:

176

answers:

6

The more I use ASP.NET, the more if (!IsPostBack) {} seems pointless...

First example:

For example, I just Googled an issue, they said use this as part of the solution:

if (!Page.IsPostBack)
{
   Page.LoadComplete += new EventHandler(Page_LoadComplete);
}

Which does exactly as coded, LoadComplete will only fire on the first load. After clicking a button, or anything that triggers a postback, the LoadComplete event is left unhooked, thus skipping the event handler. Therefore, their "fix" only works upon the first load = worthless. I promptly commented out the if (!Page.IsPostBack) {} and now the event always triggers as desired.

Second example:

I am attempting to hook events to a dynamically created button (which by the way, I can't get to work [GRR!]). I see examples showing this:

myEditToggleButton = new Button();
myEditToggleButton.ID = "editToggleButton"; 
//^GOTTA HAVE THIS FOR EVENTS TO WORK! (supposedly, I haven't seen it work...)
if (!IsPostBack)
{
   myEditToggleButton.Click += new EventHandler(myEditToggleButton_Click);
}
Controls.Add(myEditToggleButton);

Like the first example, my understanding is that the event wouldn't be hooked after the first page load, thus the button is "inert" after one click (because clicking triggered a postback).

Question:

When should you use if (!IsPostBack) {}? I am guessing it has to do with mark-up created controls only.

+2  A: 

It's for processing form data.

If you want to handle POSTed data, you only want to do so if the page actually posted data, not on first load. Hence, the IsPostBack flag.

jvenema
+5  A: 

When there is no need to repeat the operation other than the first time.

use it with expensive operations (such as getting data from a database or populating ListItems) that must be performed only the first time the page or control is loaded. If the page is posted to the server and then reloaded, there is no need to repeat the operation. By testing the value of IsPostBack, you can skip the expensive operation,

Spooks
However, with any dynamically added controls, they vaporize. Thus, for example, if you dynamically added a drop-down box, the items within at drop-down would have been vaporized with the drop-down box itself.
Yerg
@Yerg, then you would need to add those controls before the if (!IsPostBack)
harpo
@Yerg this page should help you understand IsPostBack in regards to dynamic controls. http://forums.asp.net/t/1186195.aspx
BioBuckyBall
@harpo But you still would need to hook the events, because the control you had previously hooked has gone to la-la-land due to the page reloading. What you suggested is what I have in my example above, which does not work.
Yerg
@Lucas Heneks Yes, I found that link during my Googlings of the day. That is where I learned I MUST have an ID. Danke anyway.
Yerg
A: 

What can happen if you cause a postback is you can change the state of your controls, without meaning to. For example in using a gridview, if you postback during edit mode, you will no longer have access to your edit-ed fields.

Often you need to preserve the information from disapearing on a page when you hit the server, this is the point of

if(!Page.IsPostBack)
Brett
+3  A: 

In short, you use it everytime you need to execute something ONLY on first load.

The classic usage of Page.IsPostBack is data binding / control initialization.

if(!Page.IsPostBack)
{
   //Control Initialization
   //Databinding
}

Things that are persisted on ViewState and ControlState don't need to be recreated on every postback so you check for this condition in order to avoid executing unnecessary code.

Another classic usage is getting and processing Querystring parameters. You don't need to do that on postback.

Claudio Redi
Yes, Viewstate is definitely the main force behind using it
Jared
A: 

Your event handlers should be wired up whenever the event can be fired (irrespective of PostBack status)

Also, when adding controls dynamically, be sure to observe the asp page lifecycle

nonnb
A: 

Also, you must use IsPostBack if you want to initialize controls, otherwise they will be reverted to the default on every load. This will confuse the user as when they try to use the form their entered values will get reset to your defaults.

logain