In this lesson, we're going to take a slight departure from pure C# and talk about something ASP.NET specific. While generally avoiding the minutiae of ASP.NET, the specific topic of this lesson will hopefully lead you towards building more interesting C# applications.
Step 1: Create a New Project
Either open the CS-ASP_017 Project from the provided code folder for this lesson, or setup your Default.aspx page as follows:
To illustrate this, create a new ASP.NET project called “CS-ASP_017.” This project is based on the previous lesson, and has a Default.aspx with the following Server Controls and programmatic IDs:
-
myTextBox
-
myCalendar
-
okButton
-
resultLabel
Step 2: Setting Up the PostBack Problem
Double-click the okButton, and in Default.aspx.cs, write the following code in the Page_Load and okButton_Click events:
The Page_Load event simply assigns, upon the page being loaded, the myTextBox.Text property with a default string, as well as the selected date to two days ahead of the current date. Be careful to reference the Date property that is a part of the Now property - by writing Now.Date - otherwise myCalendar.SelectedDate will hold a specific time (including hour/minutes, which is not how calendars work). Meanwhile, the okButton_Click event simply outputs the value contained in myTextBox.Text concatenated with the value in myCalendar.SelectedDate.
Step 3: Understanding the PostBack Problem
Setting up a form, or calendar, with default values is a common task, however there is a problem with this code that we wrote. If you run the application, you will notice that when you change the values for the Calendar or TextBox, those changes are never reflected after submitting them upon clicking the button. That’s because the default values always reload after every submission before the okButton_Click event is processed. The easiest solution to this problem is to include code that does one thing (assign default values) if it’s the first time the page is loaded, and do another thing if it’s not (ignore the default values).
Step 4: Referencing the IsPostBack Property
The easiest way to branch off these two separate cases is to determine whether or not the page was loaded by the bool IsPostBack property. Simply put, PostBack occurs when the okButton is clicked, and you can’t PostBack unless you first got to the page from some other means (from a direct-link, for example). This means that PostBack will never be the initial page load. Therefore, if the page was loaded via the okButton (PostBack) we can safely ignore the default values, and instead have the code read-in the user-input values.
Step 5: Resolving the Problem with a Conditional Check
Here is how we resolve the issue in code:
Noticed how the conditional checks if the page is loaded not by PostBack. Checking for the opposite would involve a bit more code and not improve readability:
Tip: Whenever you have an empty conditional (a block of code that essentially does nothing if the condition is met), you should consider inverting the expression being evaluated to check the opposite of that condition instead. If nothing else, it will make your code cleaner and easier to read.
Step 6: Understanding Code Execution and Event Timing
You may be wondering when exactly, during the page load process, the IsPostBack property is set. This refers to code execution/event timing, and is touched upon at the following URL:
In particular, notice how the event handling occurs after the initial Load procedure:
You now know how to initialize form values, as well as how to ensure that those values are only set during the initial page load. Keep this in mind as it will be important moving forward in the series. Good job!