ASP.NET Basics (Part 6): Fully Function-al - Flavor of the Month
(Page 8 of 8 )
Let's now talk a little bit about the variables used within a function, and their relationship with variables in the outside world. Usually, the variables used within a function are "local" - that is, the values assigned to them, and the changes made to them, are restricted to the function space alone.
For a clearer example of what this means, consider this simple example.
<SCRIPT language=c# runat="server">
// define a function
void changeFlavour()
{
string flavour = "tangerine";
Response.Write("(in changeFlavour) Today's flavour is " + flavour + ".
"); }
void changeFlavourAgain()
{
string flavour = "raspberry";
Response.Write("(in changeFlavourAgain) Today's flavour is " + flavour + ".
");
}
void Page_Load()
{
// invoke changeFlavour function
changeFlavour();
// invoke changeFlavourAgain function
changeFlavourAgain();
// invoke changeFlavour function
changeFlavour();
}
</SCRIPT>
And here's what you'll see:
If you take a closer look at the two functions, you will notice that both of them of define a variable called "flavour". For each invocation of the functions, a new instance of "flavour" is created, independent of any previous or subsequent reference. Such variables are aptly called "local" variables because they only exist within the function in which they are defined, and cannot be accessed outside that function.
When you attempt to access a function variable outside the function, you'll get an error - take a look at the next example and its output (or the lack of it).
<SCRIPT language=c# runat="server">
// define a function
void changeFlavour()
{
string flavour = "tangerine";
Response.Write("(in changeFlavour) Today's flavour is " + flavour + ".
"); }
void Page_Load()
{
changeFlavour();
flavour = "raspberry";
Response.Write("Today's flavour is " + flavour + ".
");
}
</SCRIPT>
Not a pretty sight. However, this doesn't mean you can't do it - all it means is that you need to declare the variable in the "global" scope.
What is the "global" scope? All variables that are defined outside the functions but within valid ASP.NET <script> tags are defined in the global scope. The following rewrite of the previous example should help to make this clearer:
<SCRIPT language=c# runat="server">
// define a global variable
string flavour = "tangerine";
// define a function
void changeFlavour()
{
flavour = "chocolate";
Response.Write("No way! I want " + flavour + ".");
}
void Page_Load()
{
Response.Write("Today's flavour is " + flavour + ".
");
// try to access the global variable
flavour = "raspberry";
Response.Write("Now its " + flavour + ".
");
// invoke changeFlavour function
changeFlavour();
}
</SCRIPT>
And now, when you view it,
The crucial thing to note here is where the "flavour" variable has been defined. Since I've defined it outside all the function blocks, it immediately has global scope and can thus be manipulated from inside other functions as well as within the main body of the program, without the dubious pleasure of a compiler error.
And that just about concludes this article. This time, you've taken a big step towards better software design, by learning how to abstract parts of your C# code into reusable functions. You've learned how to add flexibility to your functions by allowing them to accept different arguments, and how to obtain one (or more) return values from them. Finally, you've learned a little bit about how C# treats variables inside and outside functions.
Readers with a sharp memory will remember that I had introduced a nebulous thing called a "server control", way back in the first part of this series. I had gone on to explain the concept of an ASP.NET "label" control and how it could be used to avoid spaghetti-style code. In the next article, I will go beyond the plain ol' label control and give you a proper introduction to the server controls available for use in your ASP.NET scripts. These include the "textbox" control, the "dropdownlist" control, the "listbox" control, the "radiobutton" control, and many more. So make sure you come back for that one!
Note: Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 7 
