Theory
A page that reacts
Your VB.NET desktop apps did not run straight through and stop. They waited, and reacted: the user clicked a button, and your click code ran. That is event-driven programming, and ASP.NET Web Forms works the same way, over the web.
A FestConnect page does not just display once. It reacts: when the page loads, some code runs; when a student clicks Register, your registration code runs. You write small methods called handlers, each tied to an event, and ASP.NET calls the right handler when that event happens. This lesson shows how, and introduces the one twist the web adds: the postback.
Theory
Events and handlers
Two kinds of events matter. Page events come from the page itself, most importantly Page_Load, which runs every time the page is processed. Control events come from controls the user interacts with, such as a Button's Click.
For each event you care about, you write a handler: an ordinary C# method that ASP.NET runs when the event fires. You do not call these methods yourself; the framework calls them for you at the right moment. Your job is to write what should happen.
Practical
Handlers for a page event and a button click
public partial class Register : System.Web.UI.Page
{
// Page event: runs every time the page is processed
protected void Page_Load(object sender, EventArgs e)
{
lblTitle.Text = "Register for an Event";
}
// Control event: runs when the Register button is clicked
protected void btnRegister_Click(object sender, EventArgs e)
{
lblStatus.Text = "Thanks, " + txtName.Text + "! You are registered.";
}
}Formula
Postback: the page talks to itself
Here is the web twist. When the student clicks Register, the browser sends the whole form back to the same page on the server. This round trip is a postback.
On the server, ASP.NET reloads the page, runs Page_Load, then runs the button's Click handler, builds fresh HTML, and sends it back. So a click is not handled in the browser; it is a trip to the server and back. Every button click, every postback, re-runs Page_Load first.
Theory
First load vs postback: IsPostBack
Because Page_Load runs on every postback, you need a way to tell the very first visit apart from later button clicks. That is what Page.IsPostBack is for.
On the first request for the page, IsPostBack is false. On every postback after that (a button click, for example), it is true. You use it to run first-time setup only once, wrapping it in if (!IsPostBack). Typical first-time setup: filling a drop-down list of events from the database. Without the guard, you would refill that list on every single click, wiping out the user's selection.
Practical
Run setup only on the first load
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
// Runs ONCE, on the first visit only
LoadEventList(); // fill the drop-down from the database
}
// Code here (outside the guard) runs on every load and every postback
}Quiz
A student first opens Register.aspx, then clicks the Register button once. How many times does Page_Load run, and what is IsPostBack each time?
- Once total; IsPostBack is always false
- Twice: on the first load (IsPostBack false), then again on the button-click postback (IsPostBack true)
- Once, only when the button is clicked; IsPostBack is true
- Page_Load never runs unless you call it yourself
Show the answer
Twice: on the first load (IsPostBack false), then again on the button-click postback (IsPostBack true)
Page_Load runs on EVERY processing of the page. The first visit is one processing (IsPostBack is false), and clicking Register causes a postback, a second processing (IsPostBack is true), so Page_Load runs twice in total. Option A misses that a postback re-runs Page_Load. Option C forgets the first load, which also runs Page_Load. Option D is wrong: the framework calls Page_Load automatically; you never call it yourself. This is exactly why the if (!IsPostBack) guard exists: to run first-time setup once, not again on each click.
Think first
Why guard setup with if (!IsPostBack)?
What actually goes wrong if you fill your event drop-down in Page_Load WITHOUT the if (!IsPostBack) check? Then tap.
Show the answer
It re-fills the drop-down on every postback, which usually wipes out the user's choice and can hide their selection. Picture FestConnect's registration page: Page_Load fills a drop-down with the list of events. The student picks 'Robotics Workshop' and clicks Register. That click is a postback, so Page_Load runs again; if it re-loads the drop-down unconditionally, the list is rebuilt from scratch and the selected item is typically reset, so by the time your Click handler reads the choice, it may be gone or wrong. Guarding with if (!IsPostBack) means the list is built once, on the first visit, and then left alone on every click, so the student's selection survives the postback. The rule of thumb: one-time setup (loading lists, initial values) goes inside if (!IsPostBack); work that must respond to each click goes in the control's event handler.
Watch out
Event-model traps
Forgetting Page_Load re-runs: it runs on every postback, not just the first visit; guard one-time setup with if (!IsPostBack).
Rebuilding controls on every postback: reloading lists unconditionally erases the user's selection.
Expecting clicks to run in the browser: a Button Click is handled on the SERVER after a postback, not instantly in the page.
Calling handlers yourself: the framework calls Page_Load and event handlers; you just write them.
Summary
Key takeaways
- ASP.NET Web Forms is event-driven, like VB.NET desktop apps: code runs in response to events, not top to bottom once.
- Page events (Page_Load) come from the page; control events (Button Click) come from user interaction.
- You write handler methods; the framework calls them at the right time.
- A user interaction like a button click causes a postback: the page is sent to the same server page, which re-runs and re-renders.
- Page_Load runs on every processing, including every postback; Page.IsPostBack is false on the first load and true on postbacks.
- Guard one-time setup with if (!IsPostBack) so it runs once and does not erase the user's input on later clicks.
- Memory hook: click -> postback -> Page_Load -> your handler -> new HTML.