In this lesson, we will take a closer look at some key concepts we came across in the previous lesson. First, you may have noticed a handy tool called “IntelliSense” when typing out code in Visual Studio. For instance, when you typed out the word “result”, you might have seen IntelliSense pop up giving you a list of options for completing that bit of code:


Step 1: Using IntelliSense

You can then “step through” the options with your arrow keys until you find what you need, and insert it into your code. In this case, the code reference we’re looking for is the Server Control variable called resultLabel. If you hit a completion key on your keyboard (tab, space, or enter), it will autocomplete and write the rest of the variable name for you. However, we knew ahead of time that we wanted to access the Text property that is contained within resultLabel, so instead of pressing Enter or Tab, if we instead press the period key (dot accessor)on the keyboard, we are given access to a new list of IntelliSense options for properties:


Having selected the Text property using the arrow keys, you can hit the equals sign on the keyboard to complete that variable name and put the cursor in a position where you can assign whatever text you would want to be stored in that property.

As you can see, IntelliSense can become your best friend when coding in Visual Studio. It makes your typing quicker and more accurate, while also narrowing down a list of options available to you based on the context of the coding element you are accessing.

Step 2: Distinguishing Default.aspx vs Default.aspx.cs

The next thing to go over is understanding the relation ship between the Default.aspx.cs and Default.aspx files within your project. These two project files represent two sides of the same coin, and are found by clicking on the arrow beside Default.aspx in the Solution Explorer:


As implied from this file hierarchy, the files ending in .cs (denoting “c-sharp” files) can be seen as representing the code behind the Default.aspx form. When you double-click the Default.aspx file – and look at its “Source” view – you will even find this referenced on the first line of code:


And when you double-click the Default.aspx.cs file you will see this “CodeBehind” for the Default.aspx form:


When running on the web server, this code will be responsible for handling the back-end logic for the form, while the Default.aspx code handles what’s delivered to the front-end and is immediately viewable to the user. Although we will go into more detail later, it’s worth noting for now that both of these files will merge into a single file called Default.aspx when the code gets compiled.

Step 3: Server Controls in Detail

Turning our attention now to Server Controls, you will notice that the Toolbox contains an exhaustive list of Server Controls organized by category:


We’ve been working with several Server Controls in the Standard category, but some other common Controls available here are:

  • Data Controls – bind to a data source like a database.
  • Validation Controls – ensure end-users are providing inputs in an acceptable format.
  • Navigation Controls – for creating menus, and site navigation.
  • Login Controls – handle securing a site with password protection and retrieval.

While these stock Server Controls are useful for general use, there are also entire libraries of purchasable Server Controls that provide additional – and often very specific – features. Every Control has one thing that it does well that distinguishes it from all of the other controls, or else it wouldn’t exist. As we saw in the previous lesson, the TextBox Control that we used is good at receiving alphanumeric characters from the end-user, while the Button Control that we also used is great for allowing the end-user to click on it in order to take some action (such as processing the form). And, the Label Control is good at displaying information, such as the information the end-user provided and executed using those two other Controls.

Step 4: Referencing Server Controls in Code

Now, the execution of all of this occurs within the code behind the Button Control. When you double-click the button in the Design view, it takes you to this code block called okButton_Click, which is enclosed within a set of curly braces (each opening/closing set of curly braces is referred to as a “code block”):


In this case, this code block is labeled based on the name we chose for the Button, okButton, with “_Click” appended to the end of it. You can view the reference for this by going to the Properties window for the button and clicking on the Events icon (the lightning bolt beside the Properties icon):


This, essentially, binds the okButton_Click code block together with the act of clicking on the Button; when the button is clicked, it executes the code contained in okButton_Click. Whereas the fields and properties we previously dealt with described the appearance of the Button, this click-action Event – along with its code block(s) – describes what the button does. As such, you could consider this code block as the event handler for this button, in that it handles what the button executes in the event of a click.

Step 5: Understanding the okButton_Click Event

Let’s now turn to understanding what this particular code block does. You can see that we are using the names, or programmatic IDs for several of the Server Controls:

  • firstNameTextBox
  • lastNameTextBox
  • resulLabel

The first two references take whatever text the user typed in, each contained in a preset Property called firstNameTextBox.Text and lastNameTextBox.Text, respectively. And then the values for each of these text Properties become stored into separate variables, labeled firstName and lastName:



These variables can be thought of as “buckets” that are just big enough to store information of the type specified (before the named labels). In this case, that type is of type string, meaning a “string of characters.” Picture strings as a set of alpha-numeric characters strung together, one after the other, as though on a clothes line.

You declare a variable by first specifying its type, and then its label (so we can reference it by name later in code). This tells the computer to set aside in memory a “bucket” just large enough to store that information for later use, as we did here:


On this line, we are creating yet another “bucket” called result, as it’s the result of combining the values contained within firstName and lastName along with the literal string values for “Hello” and an empty space for nicer formatting. The plus sign, referred to as the “concatenation operator,” essentially glues together all of these separate string values, before dumping it into the result bucket by using the equals sign, or “assignment operator.”

And, finally, we simply set the resultLabel.Text property with the contents of result:


Recall that during design time (before the application runs) resultLabel.Text was set, by default, as an empty string. However, the code block that references this property is, nonetheless, able to manipulate the value at runtime.


Step 6: Understanding Design-time vs Runtime

The process by which this design-time/human readable code becomes compiled down to a runtime/machine-readable format, and ultimately displayed for the end-user, can be visualized as follows:


  1. Human-readable code is complied to a machine-readable format.
  2. This code is compiled into a .NET Assembly – typically a single file with a .dll file extension in the case of a web application – that will be used and referenced whenever we want to serve up a web page.
  3. A web server will launch ASP.NET, that in return calls our .dll assembly into play, requesting a definition for default.aspx
  4. Our code will execute, and ASP.NET will deliver it to the requesting web server. The web server, in return, will send it back to the end user’s web browser.

This entire compilation process gets kick-started whenever you click on the button that sends the results to the browser:


How is this able to display in the browser without first having a web server running the compiled .NET assembly? The answer is that there is a web server running locally on your computer. Visual Studio runs a mini web server called IIS Express (Internet Information Services Express), which you will notice becomes visible on your taskbar at compilation. This mini server is meant for local development purposes only:


In the next lesson, we will cover a bit more on Server Controls and how to style web pages, before delving deeper into the fundamentals of the C# language.

Lessons in this Course