Theory
The toolbox for a web page
To build FestConnect's registration form you need a text box for the student's name, a checkbox for 'send me reminders', a set of radio buttons to pick a meal preference, a label to show a welcome message, and a Register button. ASP.NET gives you all of these as ready-made server controls.
Instead of hand-writing raw HTML, you drop in tags like <asp:TextBox> and <asp:Button>, set their properties, and talk to them from your C# code. This lesson introduces the common server controls and the one behaviour that ties them together: postback.
Theory
What makes a control a server control
A server control is a tag written with the asp: prefix and marked runat="server". That attribute is the key: it tells ASP.NET the control lives on the server, so your code-behind can reach it by its id.
Because of that, each server control has three things: properties you can set or read (like a TextBox's Text), events it can raise (like a Button's Click), and it renders to HTML for the browser. So a <asp:TextBox> you place in the markup becomes an ordinary HTML input box for the visitor, but on the server it is a full object you can program.
At a glance
| Control | What it is for | Causes a postback? |
|---|---|---|
| TextBox | Let the user type text (name, email) | No, by default |
| Button | A clickable button that submits the form | Yes |
| Label | Display read-only text to the user | No |
| CheckBox | A single on or off choice | No, by default |
| RadioButton | Pick one option from a group | No, by default |
| LinkButton | Looks like a link, acts like a button | Yes |
| ImageMap | An image with clickable regions | Yes, when a hotspot is clicked |
Practical
A slice of the FestConnect registration form (.aspx)
<form runat="server">
<asp:Label id="lblName" Text="Your name:" runat="server" />
<asp:TextBox id="txtName" runat="server" />
<asp:CheckBox id="chkReminders" Text="Send me reminders" runat="server" />
<asp:RadioButton id="rbVeg" GroupName="meal" Text="Veg" runat="server" />
<asp:RadioButton id="rbNonVeg" GroupName="meal" Text="Non-veg" runat="server" />
<asp:Button id="btnRegister" Text="Register" OnClick="btnRegister_Click" runat="server" />
<asp:Label id="lblStatus" runat="server" />
</form>This example runs in Gri-Learn on the web, where you can edit it and see the output.
Practical
Reading those controls in code-behind
protected void btnRegister_Click(object sender, EventArgs e)
{
string name = txtName.Text; // read the TextBox
bool wantsReminders = chkReminders.Checked; // read the CheckBox
string meal = rbVeg.Checked ? "Veg" : "Non-veg";
lblStatus.Text = name + " registered (" + meal + ")."; // write the Label
}Formula
Which controls cause a postback
Postback is what sends the form to the server so your code can run. Button and LinkButton cause a postback when clicked, and an ImageMap posts back when a hotspot is clicked. That is how you trigger a Click handler.
By default a TextBox, CheckBox or RadioButton does NOT post back on its own; it just holds a value that is sent along with the next postback. If you want one of them to post back the instant it changes, you set its AutoPostBack property to true. Rule of thumb: buttons act, inputs wait.
Quiz
On the FestConnect form, the student types a name in the TextBox, ticks the CheckBox, and clicks the Register Button. Which control causes the postback that runs your server code?
- The TextBox, as soon as the name is typed
- The Button, when it is clicked
- The CheckBox, when it is ticked
- None of them; the page reloads on a timer
Show the answer
The Button, when it is clicked
The Button causes the postback: clicking it submits the form to the server, which runs your btnRegister_Click handler. By default the TextBox (option A) and CheckBox (option C) do NOT post back on their own; they simply hold their values (the typed name, the ticked state) to be sent along with the next postback, unless you set AutoPostBack to true on them. Option D is invented: ASP.NET pages do not reload on a timer. So buttons act (postback), inputs wait. That is why the student's typed name and ticked box are available inside the button's Click handler when it finally runs.
Think first
Why use an asp:TextBox instead of a plain HTML input?
A browser already has an <input> box. What does wrapping it as an <asp:TextBox runat="server"> actually buy you? Then tap.
Show the answer
It turns a dumb HTML element into a PROGRAMMABLE server object. A plain <input> is just markup the browser shows; your server code cannot easily read or change it by name. An <asp:TextBox runat="server"> still renders as an ordinary input for the visitor, but on the server it is an object with an id, so your code-behind can read txtName.Text, set it, validate it, disable it, or style it from C#. It also keeps its value across postbacks automatically (this is called view state), so after a click the box still shows what the user typed. And it plugs into the event model, validation controls, and data binding you will meet later. In short: same HTML for the browser, but a full, controllable object on the server, which is the whole point of Web Forms controls. Convenience and control, at the cost of a little server overhead.
Summary
Key takeaways
- Server controls are ready-made building blocks written with the asp: prefix and runat=server, so the server can program them.
- Each has properties (TextBox.Text), can raise events (Button.Click), and renders to HTML for the browser.
- Common controls: TextBox (input), Button (submit), Label (display), CheckBox (on/off), RadioButton (one of a group), LinkButton (link that acts as a button), ImageMap (clickable image regions).
- Button, LinkButton and ImageMap cause postbacks; TextBox, CheckBox and RadioButton do not by default (set AutoPostBack to change that).
- In code-behind you read and write controls by id: txtName.Text, chkReminders.Checked, lblStatus.Text.
- A server control keeps its value across postbacks (view state) and plugs into events, validation, and data binding.
- Memory hook: buttons act, inputs wait; runat=server makes it programmable.