ASP Primer: Sending a Response
Response.Write: Talking to the User
You will probably find yourself using Response.Write more than anything else in ASP. It is used to send output to the browser for the user. You will also find that you will use Response.Write frequently when debugging your pages and applications.
So, how does it work?
It's pretty simple really. Whatever you put in a Response.Write statement gets sent to the web browser. It "writes" to the browser. Here is how it works:
<% Response.Write "Hello!" %>
The result would be the word "Hello!" displayed in the browser. It would appear in the default style for your page.
Now, let's get a bit more creative. Let's make "Hello!" bold and blue. Add this to Response.Write:
"<b><font color="#0000FF">Hello!</font></b>" %>
Now you have mixed standard HTML into what you are outputting to the browser. Since the browser interprets the HTML that it receives, the result is "Hello!".
So, why would you ever want to use HTML with a Response.Write? Isn't that just an extra unnecessary step?
Imagine this, let's say you have a password protected page. When a person logs into your page you want to display one of two messages; "Congratulations!" or "Login Incorrect". You also decide that you want a successful login to be displayed in blue while an unsuccessful login would be displayed in red.
By using Response.Write in and If .. Then statement you can easily make any changes to text that you would like displayed. Here is a short excerpt of some code showing how this might work:
<% Option Explicit %>
<% Dim strPassword %>
<% If strPassword = "valid" then %>
"<font color="#0000FF">Congratulations!</font>" %>
<% Else %>
"<font color="#FF0000">Login Incorrect</font>" %>
<% End If %>
You can also use Response.Write to output variable values and other data. Let's say you wanted to display the value of a variable. Here's how it works:
<% Option Explicit %>
<% Dim strWinner %>
<% strWinner = "Johnathan Smith" %>
<% Response.Write "Lottery winner: " & strWinner %>
You can use the ampersand to connect a phrase with a variable that you want to display. The result of the code above would be:
Lottery winner: Johnathan Smith
You can also output the results of some of those built-in functions that we covered in the last section. Here's an example of how to display today's date:
<% Response.Write "Today's date: " & Date() %>
Is that all there is to it?
Pretty much. Response.Write is about as straight-forward as it gets.
There is, however, one other very important use for Response.Write that I'd like to cover - debugging. Unless you are both a master typist and master coder it is very unlikely that you will ever write an ASP application that runs perfectly right out of the gate. That's where debugging and Response.Write come into play.
Once you have cleaned up all of the typos that you may have made when writing your code, there is still no guarantee that the code will run as planned. It may give you the wrong results in a mathematical calculation or spit out other incorrect information. When this happens, most ASP developers will drop several different Response.Write statements in their code to narrow down the problem. Here are some different situations where Response.Write might be effective:
Wrong results - Try putting a Response.Write after you change the value of any variable that is connected with the wrong result. This way your application will basically give you a play-by-play of what it is doing. Hopefully, by walking through the calculations step-by-step you can pinpoint where things go awry.
Skipped code - Sometimes an If .. Then or other conditional statement may not react like you expect. By placing a Response.Write in your conditional statements, you can determine whether or not the code inside the conditional is executed. This will allow you to trace the flow of your code and determine whether or not your conditional statements are resolving as you had expected.
Don't forget to delete the extra Response.Write statements out of your code once you have squashed your bug(s). We'll discuss other debugging techniques as we go through this series.