ASP.NET

Friday, July 3, 2009

An application is defined as the set of files in an IIS virtual directory and its subdirectories. The files that constitute an ASP.NET application typically include:
•A Global.asax file containing application-level program directives, handlers for application and session-level events, and declarations of objects that are globally accessible to all parts of the application.
•A Config.web file containing configuration information.
•One or more ASPX files containing Web Forms.
•One or more code files written in C# containing the application's code.
Code files aren't always present in the virtual directory because code can optionally be placed in the ASPX files. But most Web Forms applications especially those created with Visual Studio.NET segregate code and data into separate files
Global.asax is to ASP.NET what Global.asa is to ASP. If you want to trap events such as Application_Start, Application_End, Session_Start, and Session_End (which are fired when applications start and stop and sessions begin and end) you put the event handlers in Global.asax. Typical uses for these event handlers include initializing state for each user and manipulating program counters. Config.web is new to ASP.NET. It's an XML-formatted file that stores an application's configuration settings. It's a welcome improvement over ASP, whose insistence on storing configuration data in the IIS metabase makes moving an application from one machine to another a chore. Plus, because it's a text file, Config.web can be edited with a text editor like Notepad.
Application Pages
Each ASPX file included in a Web Forms application constitutes one page of the application. The first time a page is requested, ASP.NET dynamically generates a class to represent that page by deriving from System.Web.UI.Page. After compiling the derived class and caching the compiled executable in a special directory (so subsequent requests for the same page will execute much faster), ASP.NET instantiates the class and executes it to generate HTML to return to the client.
The HTML included in the output stream comes from the HTML present in the ASPX file, the page's controls, and any scripts that write out HTML of their own. After it's executed, the instance of the page object is discarded. Thus, a page object's lifetime lasts from the time it's instantiated following each new request, until the request is complete.
During its lifetime, a page undergoes several distinct phases. As it enters each new phase, the page fires an event that can be processed with a server-side script. For Web Forms developers, the most important page-level event is Page_Load, which is called each time the page is instantiated. Because Page_Load is called before the page is rendered to the client, it's a great place to perform any one-time initializations that need to happen before rendering takes place. Developers can respond to Page_Load events by implementing a handler in a script:


A common use for Page_Load events is to query a database for information needed to initialize one or more of the page's controls. Page_Load can even be used to populate the page with controls programmatically.
Because ASPX scripts execute in the context of a class derived from System.Web.UI.Page, they can call System Web.UI.Page methods and access System.Web.UI.Page properties. Those properties include Request, Response, Server, Application, and Session, which provide access to the ASP objects of the same name.
The Page class also exposes a Boolean property named IsPostBack that's often used by Page_Load handlers. In many cases, initializations performed in Page_Load only need to happen when the page is requested anew, not during postbacks. IsPostBack tells you whether your code is executing within a postback (IsPostBack==true) or in response to a new request (IsPostBack==false). The following Page_Load handler initializes a control with the results from a database query, but only if it's called outside of a postback:

Such code is often used to avoid requerying a database (and reinitializing a form's controls) when postbacks occur.
Page-level Directives
For the most part, the component of ASP.NET that compiles pages into executable form the page compiler does its work behind the scenes and without any input from you. However, you can add your two cents to the settings that it uses by including page-level directives in your ASPX files. The syntax for page-level directives is:

For example, including the following directive at the top of an ASPX file turns tracing on.


Tracing is a handy debugging aid that enables Web Forms to write trace output to Web pages. Similarly, the following statement enables tracing and identifies C# as the default language for scripts embedded within the page.

For a complete description of all the options that ASP.NET places at your disposal through page-level directives, consult the document titled " ASP.NET Page Syntax".
In some cases, page-level directives are optional. In certain scenarios, however, they're very much required. Web Forms that use custom controls, for example, require Register directives to define tag prefixes for those controls.
Separating Code and Data
One feature that's made accessible by page-level directives is code-behind, which enables Web Form code and data to be placed in separate files you can separate the two by moving the code to a CS file
Controls
The .NET Framework class library, which provides the classes common to all .NET applications, contains several classes that represent server controls. These classes are divided into two categories: HTML controls and Web controls.



HTML controls are created from classes in the .NET Framework class library's System.Web.UI.HtmlControls namespace. All HTML control classes derive, either directly or indirectly, from System.Web.UI.HtmlControls.HtmlControl. HTML control classes are instantiated by adding RunAt="server" to ordinary HTML tags. For example, the following statement declares a standard HTML text input field.

But this statement declares an instance of HtmlInputText.

Within an tag of this type, you can use standard HTML attributes such as Name and Value. You can also use attributes that map to the properties defined in the corresponding HTML control class. For example, the statement

assigns the value "UserName" to the HtmlInputText property named ID. This ID can be used to reference the control in server-side scripts. The following C# statement reads the text that the user entered into the control.
string strUserName = UserName.Value
documents all the HTML control classes and the HTML tags to which they correspond. These classes are provided primarily to ease the chore of migrating existing Web applications (particularly ASP applications) to ASP.NET. For example, rather than replacing all instances of with , you can simply add RunAt="server" to the existing tags to convert them into living, breathing Web Forms controls.

HTML controls are little more than glorified wrappers around existing HTML tags, but Web controls are richer and more ambitious in scope. For example, you can use a Calendar control to display calendars in Web Forms and let users pick dates using a visual (and self-contained) UI. Some Web controls even adapt themselves to the browser that they're rendered to. For example, a RequiredFieldValidator control rendered to an uplevel browser includes client-side script that validates user input locally. The same control rendered to a browser that doesn't support scripting, however, uses round-trips to the server to flag blank fields.
The attributes that you can apply to tags when declaring Web controls are determined by the properties defined in the respective control classes. For example, because the TextBox class exposes properties named TextMode and Text, all of the following statements are valid:

The properties exposed by individual controls vary from control to control, but all Web controls, with the exception of Repeater, inherit a common set of properties from the base class WebControl.
Syntax is important when using these properties, particularly the Font, Width, Height, and XxxColor properties. The Font property has subproperties named Bold, Italic, Name, Names, Size, Strikeout, Underline, and Overline. To assign a value to a subproperty, separate the property name (Font) and the subproperty name with a hyphen, as in

The Font-Size property can be specified using pixels as the unit of measurement using either of the following syntactical conventions:

Or it can be expressed in points by replacing px with pt:

Width, Height, and BorderWidth values can be expressed in pixels, points, or percentages. Pixels is the default, so omitting px, pt, and % is the equivalent of writing out px.

Both HTML and Web controls support an event model that permits control events, such as pushbutton clicks, to be connected to server-side event handlers. You've seen one example of this already in below figure, where an OnClick attribute was used to connect the Calculate button to the OnCalculate method. The .NET SDK lists all the events defined by all the control types. In general, you can connect an event to a handler by prefixing the event name with On and using it as an attribute. For example, ListBox controls fire SelectedIndexChanged events each time the selection changes. The following statement connects SelectedIndexChanged events to a handler named OnNewSelection:

Note the parameter that sets AutoPostBack equal to True. To avoid unnecessary round-trips to the server, ListBox selection changes only prompt postbacks if AutoPostBack is True. In the absence of automatic postbacks, a server-side script will only see SelectedIndexChanged events when the form is posted back to the server in response to other stimuli. AutoPostBack is supported by CheckBox, CheckBoxList, DropDownList, ListBox, TextBox, RadioButton, and RadioButtonList controls. In every case, it defaults to False. Don't forget to toggle AutoPostBack on if you want to handle events from these control types. Also, be aware that AutoPostBack does nothing in downlevel browsers that don't support JavaScript.
Space constraints don't permit me to examine every one of the Web control classes in detail, but once you grasp the basics, the rest is easy to figure out. The following sections will give you a quick survey of the Web control classes in the .NET Framework class library and sample code showing how to use them in Web Forms applications.
Label Controls
Label controls, which are denoted by tags, display text in Web pages. You specify the control's text using System.Web.UI.WebControls.Label's Text property. The following statement creates a Label control and assigns it the text "Hello":

To modify a Label control's text during the course of an application's execution, you can simply assign the control an ID and use a server-side script to write a new value to the control's Text property:


// In a C# script

HyperLink controls let you place hyperlinks (the equivalent of tags) in Web pages. Properties specific to HyperLink include Text, NavigateUrl, ImageUrl, and Target. Text specifies the control text, and NavigateUrl identifies the URL that the hyperlink points to.

If you'd like, you can replace Text with ImageUrl to display the hyperlink as an image instead of a text string:

You can use the Target property to reference a window or frame at the URL named by NavigateUrl. For example, adding a "Target=_new" attribute to an tag opens the resource in a new browser window.
Image Controls
Image controls are to Web Forms as tags are to HTML. Their purpose is to display images in Web pages. Control-specific properties include AlternateText, ImageAlign, ImageUrl, and Font. The following statement declares an Image control whose alternate text (the text displayed when the image file isn't available and when you mouse over the image) is "Company Logo" and whose appearance comes from Logo.jpg:

You can use the ImageAlign attribute to specify the image's alignment with respect to the text that surrounds it, and the Font property to change the font used for the alternate text.
TextBox Controls
TextBox controls are the Web Forms equivalent of and
Setting TextMode to "password" tells the control to act as a password control by displaying asterisks instead of characters:

The "multiline" setting creates a multiline text input field:

To read text from a TextBox control in a server-side script, simply read the control's Text property:

If the text in a TextBox has changed when the form is posted back to the server, the control fires a TextChanged event that can be handled by a script. The following example demonstrates how to synchronize the contents of a label control and a TextBox control by updating the label control each time a postback occurs. Note the AutoPostBack setting:

Be aware that TextChanged events are not fired each time a new character is typed into the TextBox. AutoPostBack="true" causes a postback to occur only when the TextBox loses the input focus after its contents are modified.
CheckBox and CheckBoxList Controls
CheckBox controls add checkboxes to Web pages. Useful CheckBox properties include Text, TextAlign, and Checked. The following statement creates an unchecked checkbox:

This one creates a checkbox that's checked and whose text is aligned to the left (rather than the right) of the checkbox:

To check the state of a checkbox from a server-side script, read the Checked property, which is a Boolean:

CheckBox controls fire CheckedChanged events when they're checked and unchecked. Use OnCheckedChanged to connect CheckedChanged events to a handler implemented in a server-side script. Also, don't forget to set AutoPostBack to True
The CheckBoxList control lets you display groups of checkboxes and exercise control over the group's layout. ListItem statements define the individual checkboxes within the group. Setting a ListItem's Selected property to True checks the corresponding checkbox:

Two CheckBoxList properties affect the layout of the checkboxes: RepeatColumns and RepeatDirection. RepeatColumns specifies the number of columns the checkboxes are to be divided into (default=1); RepeatDirection specifies whether the checkboxes are to be laid out in row-first order (RepeatDirection="horizontal") or column-first order (RepeatDirection="vertical"). Vertical is the default. Use the CellPadding and CellSpacing properties to fine-tune the spacing between checkboxes.
RadioButton and RadioButtonList Controls
RadioButton controls () enable users to select from a group of mutually exclusive options. RadioButtons behave very much like CheckBoxes (in fact, the RadioButton class even derives from CheckBox), but they add one important characteristic of their own: when one RadioButton is checked, the other RadioButtons in the same group are automatically unchecked. To support grouping, RadioButton adds one property, GroupName, to the list of properties it inherits from CheckBox. The following example creates two groups of RadioButtonsâ€"one containing three controls and the other containing two and checks one RadioButton in each group:

To programmatically determine whether a RadioButton is selected, read the button's Checked property. To trap notifications indicating that a RadioButton's state has changed, use the OnCheckChanged and AutoPostBack attributes.
RadioButtonList controls provide an alternate means for creating and grouping RadioButtons. The following code is equivalent to the previous code:

Note the lack of GroupName attributes. They're not needed with RadioButtonLists because grouping is implicit (each RadioButtonList constitutes its own group). Also be aware that like CheckBoxList controls, RadioButtonLists feature RepeatColumns and RepeatDirection properties that you can use to control the buttons' layout, as well as CellPadding and CellSpacing properties for tweaking their spacing. To find out which button in a RadioButtonList is selected, assign the RadioButtonList an ID and read its SelectedIndex property from a server-side script. SelectedIndex returns the zero-based index of the button that's selected.
ListBox and DropDownList Controls
ListBox and DropDownList controls are analagous to
These statements create a DropDownList containing the same items:

This server-side script, written in C#, modifies a pair of Label controls whose IDs are "Label1" and "Label2" to report which items were selected from the lists:

To permit a user to select multiple items from a listbox, add

In a derived class, you can use the SelectedIndices property that ListBox inherits from ListControl to identify the items selected in a multiple-selection ListBox. But because SelectedIndices is declared protected rather than public, you can't use it with an ordinary ListBox. (Note: In Beta 2, SelectedIndices will probably change from protected to internal, in which case it wouldn't even be available in classes derived from ListBox.) To read the selection from a multiple-selection ListBox, use the control's Items collection to enumerate the ListBox items and check each item's Selected property.
ListBoxes, DropDownLists, CheckBoxLists, and RadioButtonLists fire SelectedIndexChanged events upon the next server postback when the selection changes. You can add an OnSelectedIndexChanged attribute to a tag (for example, ) to wire up a handler. When the handler is activated, use the SelectedIndex or SelectedItem property to determine which item is currently selected.
Sometimes it's useful to fill list controls programmatically, based on information gathered at runtime. Here's one way to populate a ListBox from a server-side script:

And here's another wayâ€"one that utilizes System.Collections.ArrayList:

This sample works because ListBox and other ListControl-derived classes have properties named DataSource that can be initialized with a reference to any object that implements an ICollection interface, and because ArrayList and many other collection types provided by the .NET Framework class library implement ICollection. Calling the control's DataBind method tells the control to enumerate the collection's items and to bind them by displaying them. I'll have more to say about data binding in the section on list-bound controls later in this article.
Button, LinkButton, and ImageButton Controls
Three server controls Button, LinkButton, and ImageButton can be used to submit forms to the server to allow server-side processing to take place. All three control types do essentially the same thing; the difference is how they render themselves to the screen. Button controls resemble standard pushbuttons. LinkButtons look like hyperlinked text, and ImageButtons derive their looks from user-supplied images. When clicked, all three controls fire Command and Click events that can be handled in server-side scripts. In addition, ImageButtons transmit x and y coordinates revealing where in the image the click occurred.
All three classes expose properties named CommandArgument and CommandName that can be used to customize the information passed in Command events. In addition, Button and LinkButton expose their text through Text properties. ImageButton lacks a Text property but offers ImageUrl and ImageAlign properties instead.
The following code creates a Button and a LinkButton and connects them to a Click handler named OnSubmit:

An ImageButton can't be connected to the same Click handler as a Button or LinkButton because its Click event is prototyped differently: it receives an ImageClickEventArgs rather than an EventArgs. If the handler wants to know exactly where the click occurred, it can obtain the x and y coordinates from the ImageClickEventArgs:

The coordinates encapsulated in an ImageClickEventArgs are measured in pixels and are relative to the upper-left corner of the ImageButton.
Table Controls
Table controls () create HTML tables and, combined with TableRow and TableCell controls, provide a functional alternative to

, ,
, and tags. The following example creates a table containing two rows and two columns:

By default, a table defined this way has no border. To add a border, set the BorderWidth attribute to 1.
If you'd like to add a background image as well, use the BackImageUrl attribute. BackImageUrl is one of several properties that Table adds to those it inherits from WebControl. Others include CellPadding, CellSpacing, GridLines, HorizontalAlign, and Rows. The TableRow and TableCell classes expose properties of their own that provide a high degree of control over the table's appearance and enable scripts to programmatically alter or enumerate a table's contents.
The following creates a table identical to the previous one, but assigns text to the table's cells using TableCell's Text property:

Defining a table this way (and assigning IDs to TableCell controls) enables server-side scripts to easily modify a table's contents by changing the Text properties of individual TableCells. Also note that you can use TableHeaderCell controls in lieu of TableCells to define table headers. TableHeaderCell controls evaluate to 		tags. Many browsers render and tags identically.
Panel Controls
Panels are controls that are used to create logical groupings of other controls. A Panel generally has no UI of its own, but it is useful for controlling the visibility of other controls on the page. For example, suppose you declare three

To hide these Label controls, set their Visible properties to False:

But if you grouped the Label controls with a Panel control, one statement would make all three disappear from sight:

Calendar Control
The controls that I've discussed thus far are little more than wrappers around simple HTML tags. Not so with the Calendar control. A single Calendar control expands to more than 100 lines of HTML when it's rendered to a browser.
Calendar controls are ideal for letting users choose dates and date ranges using a highly visual UI. Getting a basic Calendar control up and running in a Web page is simplicity itself:

But this simple example belies the sheer number of options that the Calendar class offers. Calendar defines 28 properties in addition to those it inherits from its base class. Many Calendar properties have subproperties that further expand the number of options available. These properties and subproperties let you customize the control's appearance in just about any way you like. They also enable you to get or set the date (or date range) selected in the control. The Calendar class also defines events named SelectionChanged and VisibleMonthChanged that allow server-side scripts to respond to selection changes and to changes in the month that is currently displayed.

full-blown Web Forms application that displays a stylized calendar and responds to SelectionChanged events by updating a Label control positioned just above the Calendar control. Clicking the Submit button activates a server-side script that reads the currently selected date from the control and displays it in the browser in "long date" format

AdRotator Control
I won't say a lot about the AdRotator control other than to point out that it's functionally similar to the ad rotator control that comes with ASP. Its purpose is to display rotating banner ads using configuration parameters encoded in an XML file.
List-Bound Controls
One of the tasks that Web applications are asked to perform most frequently involves retrieving data from a database and displaying it in a Web page. ASP.NET does several things to help out with this mundane but important chore. First, it interoperates with a new data access technology called ADO.NET that was specifically designed to meet the needs of data-handling applications deployed over the Web. Second, it genericizes the concept of a data source so applications can work with a wide range of data providers, from relational databases to in-memory XML data stores to simple arrays. Finally, it includes a family of Web controls that know how to read data from data sources and render visual representations to Web pages. Members of that family are known as the list-bound controls.
Three of the classes in System.Web.UI.WebControls represent list-bound controls: Repeater, DataList, and DataGrid. A full treatment of these classes could fill a small book, but I want to give you a taste of what they're like, because in addition to being among the most complex classes in the .NET Framework class library, they're also some of the most useful especially to developers building e-commerce applications.
For starters, suppose you want to create a Web page that retrieves a set of records from a back-end database and displays those records in a table. You could use ASP and ADO to query the database and build the table yourself, or you could use ADO.NET and a DataGrid control and let the DataGrid build the table. The database used in this example is the Pubs database that comes with the .NET SDK. The page's Page_Load handler uses a SQL SELECT command to query the database for a list of all the records in the Titles table. (Note the if clause that prevents the query from being performed during postbacks.) Each record returned from the query contains information about one bookâ€"its title, price, publication date, and so on. The statement

connects the results of the query to the DataGrid control, and the statement

binds the control to the data. The DataGrid itself is declared with an tag and assigned the ID MyDataGrid.
The DataGrid control renders back to the browser as a standard HTML table containing all the data returned by the query, which currently consists of all the rows and columns (including column names) in the Titles table of the Pubs database.

DataGrid Control
Table shows far more information than it needs to, and it could definitely be formatted more attractively. Plus, if I want customers to buy books from my Web page, they'll need a way to add items to a shopping cart. I won't go so far as to implement a full-blown shopping cart, but I'll at least lay the groundwork for you.
The tag now includes a long list of attributes used to customize the table's appearance. The AutoGenerateColumns attribute is particularly important, because setting it to False prevents the DataGrid from automatically generating columns based on the fields it finds in the database. Now I can control the columns displayed by adding and tags to the tag. A BoundColumn is a DataGrid column that is bound to a particular field in the database specifically, to the field identified by the BoundColumn's DataField property. A ButtonColumn contains buttons instead of ordinary text. This ButtonColumn inserts an "Add to Cart" command into each row of the table. Clicking a button activates the event handler, OnItemAction, which displays the name of the item that the user selected at the bottom of the page.

Selecting an Item
The many attributes used in the are emblematic of the myriad formatting options that the DataGrid class offers. In particular, note how the control's HeaderStyle, ItemStyle, and AlternatingItemStyle properties (and their subproperties) are used to customize the appearance of the rows. Also note how ItemStyle-HorizontalAlignment is used to right-align the numbers in the Price column and center the buttons in the Action column, and how DataFormatString is used to format the numbers in the Price column as currency values. Unlike Windows-based controls, which offer an extremely limited number of formatting options, DataGrid controls put you in charge of virtually every aspect of their appearance.
These examples barely scratch the surface of what you can do with DataGrid controls, and they don't even address DataList and Repeater controls. But hopefully you get the idea. List-bound controls ease the chore of displaying structured data. The more you use ASP.NET, the more you'll appreciate the power of these controls. For more information about list-bound controls and examples demonstrating how to use templates to further customize their appearance, read "Using the ASP+ List-Bound Controls".
Validation Controls
The Web controls family includes a set of controls whose purpose isn't to solicit input, but to validate it. Consider the mortgage calculator presented earlier in this article. A real-life version should display an error message if the user fails to fill in a field or fills it in improperly. That's what validation controls are for.
RequiredFieldValidator controls to check for blank fields, and RegularExpressionValidator controls to make sure that entries are well-formed specifically, that the Principal and Months fields contain only numbers and that the Rate field contains numbers and a period. RequiredFieldValidator controls verify that the content of the controls that they're attached to is non-null, while RegularExpressionValidator controls validate a control's content against a regular expression provided by the programmer. (Unfortunately, RegularExpressionValidator controls can't be used to ensure that the fields are also filled in.) For example, setting a RegularExpressionValidator's ValidationExpression property to [0-9]* specifies that any number of digits (and digits only) will be accepted; setting it to [0-9]\.[0-9]* limits valid text to strings of the form *.*, where * is any numeric character.
the Calculate button is clicked but an entry is missing: an error message flags the offending field. You control the error message and its placement. Among other things, this means that you no longer need code in OnCalculate to check for null strings. If the Calculate button is clicked and a field is blank, the form is never submitted, therefore the script isn't executed.
Validating Input
each TextBox control now has corresponding RequiredFieldValidator and RegularExpressionValidator controls. The table used to align the form's control has been extended with a third column that hosts the validators. Before rendering themselves to the output stream, validator controls check to see whether the browser that they're rendering to supports scripting. If the answer is yes, they return client-side script that performs validation checking locally. If the answer is no, they omit the client-side script and return HTML that forces a return trip to the server so the server can do the checking. Either way, you win. You get a page that works no matter what kind of browser is being used. And you get a page that works more efficiently with intelligent browsers.
In addition to the RequiredFieldValidator and RegularExpressionValidator controls, the .NET Framework also provides:
•CompareValidator control, which validates input by comparing it to a value i another control or a value that you specify.
•RangeValidator control, which verifies that an input value falls within a specified range.
•CustomValidator control, which validates input using an algorithm you supply.
•ValidationSummary control, which displays a summary of all the validation errors encountered on a page. For more information regarding these controls, visit MSDN® Online's Web Forms Validation page.

Custom Controls
It should be abundantly clear by now that the System.Web.UI.WebControls namespace includes a rich variety of Web controls that ease the chore of building sophisticated Web Forms. But there's more. If none of the existing controls fit the bill, you can write Web controls of your own. Such controls are variously referred to as custom controls, custom server controls, or custom Web controls. A full treatment of custom controls merits an article of its own.
This example, Headline.aspx, is a simple Web Form that employs a custom control named Headline. The Register directive equates the tag prefix "demo" to the namespace MSDNMagControls. The source code for the Headline control is contained in Headline.cs. That file declares a namespace named MSDNMagControls, which contains a class named Headline. Headline is derived from System.Web.UI.Control, which forms the basis for all server controls. To render the Headline control to the browser, the framework calls the control's virtual Render method and passes a reference to an HtmlTextWriter object the control can use to write text to the HTML output stream. Headline overrides the Render method and outputs the text stored in a field named _Text, which is exposed through a property named Text, surrounded by

tags. The result? In Headline.aspx,

However, the actual rendering is done by the control. Headline could be extended with additional properties, methods, and even events to make it a first-class Web control.
Something that's not obvious from the source code figures is how the ASPX file knows where to find the compiled CS file containing the custom control. In order for this example to work, you must compile the CS file into a DLL and store it in a directory named \bin under the application's virtual root directory. The following command uses the C# compiler to compile Headline.cs, creating a DLL named MSDNMagControls.dll:

Once the DLL is created, placing it in the \bin directory makes it available to Web Forms that are part of the corresponding app .
User Controls
So far the term "control" has referred either to HTML controls or Web controls. Web Forms support a third type of control, which the documentation refers to as user controls. A user control is a chunk of reusable Web Forms code packaged in an ASCX file. Generally, it's all or part of a form without the
tags. To employ a user control, you open an ASPX file and add a Register directive that registers a tag name and tag prefix for the user control and identifies the user control's ASCX file. You then declare an instance of the user control by inserting a tag containing the user control's tag name and prefix into a form in the ASPX file.
User Control Login Screen.
The user control contributes the part of the form that appears between the horizontal rules. Everything else comes from the ASPX file. In Login.aspx, this statement registers the user control.

This statement declares an instance of it and initializes its background color.

BackColor is a valid attribute because the script in Login.ascx implements a property of that name and maps it to the BackColor property of the table used to align the user control's controls. The ASCX file also defines properties named UserName and Password. UserName is used in the page's Page_Load handler to read the name that the user entered.
User controls let you package snippets of Web Forms in such a way that they can be reused as components in other Web Forms. Additionally, user controls can contribute more than just a user interface. The user control in Login.ascx includes validation logic that rejects the login (prevents the form from being submitted) if either input field is blank, if the user name contains less than five characters, or if the password contains less than eight. In the real world, a user control such as this one could be enhanced to perform real authentication. Then, building a screen that knows how to validate logins would be as simple as adding the user control to a form.
As a syntactical matter, note that unlike ASPX files, ASCX files can't include Page directives. They can, however, contain Control directives that accomplish the same objective.
By
Usama Wahab Khan and Atif Shahzad
share this post
Share to Facebook Share to Twitter Share to Google+ Share to Stumble Upon Share to Evernote Share to Blogger Share to Email Share to Yahoo Messenger More...

Posted by Usama Wahab Khan at 10:10 PM  

Labels: , ,

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)