dot net information

@ Control

Defines user-control (.ascx file) specific attributes that are used by the ASP.NET page parser and compiler. This directive can be used only with user controls.

Attributes
AutoEventWireup
Indicates whether the page's events are autowired. true if event autowiring is enabled; otherwise, false. The default is true. For more information, see Web Server Control Event Model.
ClassName
Specifies the class name for the page that will be dynamically compiled automatically when the page is requested. This value can be any valid class name but should not include a namespace.
CompilerOptions
A string containing compiler options used to compile the user control. In C# and Visual Basic .NET, this is a sequence of compiler command-line switches.
Debug
Indicates whether the page should be compiled with debug symbols. true if the page should be compiled with debug symbols; otherwise, false.
Description
Provides a text description of the page. Supports any string description.
EnableViewState
Indicates whether view state for the user control is maintained across page requests. true if view state is maintained; otherwise, false. The default is true.
Explicit
Determines whether the page is compiled using the Visual Basic Option Explicit mode. true indicates that the Visual Basic explicit compile option is enabled and that all variables must be declared using a Dim, Private, Public, or ReDim statement; otherwise, false. The default is false.
Note This attribute is ignored by languages other than Visual Basic .NET. Also, this option is set to true in the Machine.config configuration file. For more information, see Machine Configuration Files.
Inherits
Defines a code-behind class for the user control to inherit. This can be any class derived from the UserControl class. For information about code-behind classes, see Web Forms Code Model.
Language
Specifies the language used when compiling all inline-rendering ( and ) and server-side script blocks within the user control. Values can represent any .NET-supported language, including Visual Basic, C#, or JScript .NET.
Strict
Indicates that the page should be compiled using the Visual Basic Option Strict mode. true if Option Strict is enabled; otherwise, false. The default is false.
Note This attribute is ignored by languages other than Visual Basic .NET.
Src
Specifies the source file name of the code-behind class to dynamically compile when the user control is requested. You can choose to include programming logic for your page either in a code-behind class or in a code declaration block in the .ascx file.
Note RAD designers, such as Visual Studio .NET, do not use this attribute. Instead, they precompile code-behind classes and then use the Inherits attribute.
WarningLevel
Indicates the compiler warning level at which you want the compiler to abort compilation for the user control. Possible values are 0 through 4. For more information, see the CompilerParameters.WarningLevel Property property.
Remarks
This directive can be used only in user controls. User controls are defined in files with the .ascx extension. You can include only one @ Control directive per .ascx file.
Example
The following code instructs the ASP.NET page compiler to use Visual Basic as the inline code language and disables saving view state across HTTP requests using the EnableViewState attribute.



@Import:

Explicitly imports a namespace into a page, making all classes and interfaces of the imported namespace available to the page. The imported namespace can be part of the .NET Framework class library or a user-defined namespace.

Attributes
namespace
The name of the namespace to import to the page. This can include any of the namespaces included in the .NET Framework or a custom namespace.
Remarks
The @ Import directive cannot have more than one namespace attribute. To import multiple namespaces, use multiple @ Import directives.
The following namespaces are automatically imported into all pages:
System
System.Collections
System.Collections.Specialized
System.Configuration
System.IO
System.Text
System.Text.RegularExpressions
System.Web
System.Web.Caching
System.Web.Security
System.Web.SessionState
System.Web.UI
System.Web.UI.HtmlControls
System.Web.UI.WebControls
Example
The following code imports the .NET Framework base-class namespace System.Net and the user-defined namespace Grocery:





@ Assembly
Links an assembly to the current page during compilation, making all the assembly's classes and interfaces available for use on the page.


Attributes
Name
A string that represents the name of the assembly to link to the page.
Note The assembly name does not include a file name extension.
Src
The path to a source file to dynamically compile and link against.
Note You cannot include a Name and a Src attribute in the same @ Assembly directive. If you want to use both, you must include more than one directive on the page.
Remarks
The compiler references the assembly at compile time, allowing early binding. Once compilation of the requested page is complete, the assembly is loaded into the application domain, allowing late binding.
Assemblies that reside in your Web application's \bin directory are automatically linked to pages within that application. Such assemblies do not require the @ Assembly directive. You can disable this functionality by removing the following line from the section of your application's Web.config file:

Note You cannot include the path to an assembly in an @ Assembly directive.
As an alternative to using the @ Assembly directive, you can use the Web.config file to link assemblies across an entire application. For more information about the Web.config file and configuring your application, see ASP.NET Configuration.
Example
The following code fragment uses two @ Assembly directives, the first to link to MyAssembly, a user-defined assembly, the second to MySource.vb, a Visual Basic .NET source file.







@ Register
Associates aliases with namespaces and class names for concise notation in custom server control syntax.


Attributes
tagprefix
An alias to associate with a namespace.
tagname
An alias to associate with a class.
Namespace
The namespace to associate with tagprefix.
Src
The location (relative or absolute) of the declarative user control file to associate with the tagprefix:tagname pair.
Assembly
The assembly in which the namespace that you are associating with tagprefix resides.
Note The assembly name does not include a file name extension.
Remarks
Including the @ Register directive in a page or user control allows you to lay out custom server controls or user controls using declarative custom server control syntax.
Use the @ Register directive in the following situations.
To declaratively add a custom ASP.NET server control to a page or user control.
To add a declarative user control to a page or user control.
For declarative user controls, use the tagname, tagprefix, and src attributes. The first two are always used together as a colon-separated pair (tagprefix:tagname) when you declare the control in the page. The src attribute value can be either a relative or absolute path to the user control source file from your application's root directory. For ease of use, it is recommended you use a relative path. For example, assume you store all of your application's user control files in a \usercontrol directory that is a sub-directory of your application root. To include the user control found in a usercontrol1.ascx file, include the following in the @ Register directive:
Src="~\usercontrol\usercontrol1.ascx"
The tilde (~) character represents the root directory of the application.
Note If your user control is in the same directory as the page that contains it, the src attribute value should be the name and extension of the .ascx file.
When including custom server controls that you have compiled into a .dll for use with your application, use the tagprefix with the Assembly and Namespace attributes. If you do not include the Namespace attribute, or if you assign an empty string to it, a parser error will occur.
CAUTION When you develop a custom server control, you must include it in a namespace. If you do not, it will not be accessible from an ASP.NET page. For more information about developing custom ASP.NET server controls, see Developing a Simple ASP.NET Server Control.
Example
The following code fragment uses @ Register directives to declare tagprefix and tagname aliases for a server control and a user control. The first directive declares the MyTag alias as a tag prefix for all controls residing in the MyCompany:MyNameSpace namespace. The second directive declares Acme:AdRotator as a tagprefix:tagname pair for the user control in the file Adrotator.acscx. The aliases are then used in custom server-control syntax within the form to insert an instance of each server control.

@Implements
Indicates that the current page or user control implements the specified .NET Framework interface.

Attributes
interface
The interface to be implemented on the page or user control.
Remarks
When you implement an interface in a Web Forms page, you can declare its events, methods, and properties between opening and closing tags of a

>


[Visual Basic]


>


@OutputCache
Declaratively controls the output caching policies of an ASP.NET page or a user control contained in a page. For more information about the output cache, see ASP.NET Caching Features.

Attributes
Duration
The time, in seconds, that the page or user control is cached. Setting this attribute on a page or user control establishes an expiration policy for HTTP responses from the object and will automatically cache the page or user control output.
Note This attribute is required. If you do not include it, a parser error occurs.
Location
One of the OutputCacheLocation enumeration values. The default is Any.
CAUTION This attribute is not supported for @ OutputCache directives included in user controls (.ascx files).
Shared
A Boolean value that determines whether user control output can be shared with multiple pages. The default is false. For more information, see the Remarks section.
Note This attribute is not supported for @ OutputCache directives included in ASP.NET pages (.aspx files).
VaryByCustom
Any text that represents custom output caching requirements. If this attribute is given a value of browser, the cache is varied by browser name and major version information. If a custom string is entered, you must override the HttpApplication.GetVaryByCustomString method in your application's Global.asax file.
VaryByHeader
A semicolon-separated list of HTTP headers used to vary the output cache. When this attribute is set to multiple headers, the output cache contains a different version of the requested document for each specified header.
Note Setting the VaryByHeader attribute enables caching items in all HTTP 1.1 caches, not just the ASP.NET cache. This attribute is not supported for @ OutputCache directives in user controls.
VaryByParam
A semicolon-separated list of strings used to vary the output cache. By default, these strings correspond to a query string value sent with GET method attributes, or a parameter sent using the POST method. When this attribute is set to multiple parameters, the output cache contains a different version of the requested document for each specified parameter. Possible values include none, *, and any valid query string or POST parameter name.
CAUTION This attribute is required when you output cache ASP.NET pages. It is required for user controls as well unless you have included a VaryByControl attribute in the control's @ OutputCache directive. A parser error occurs if you fail to include it. If you do not want to specify a parameter to vary cached content, set the value to none. If you want to vary the output cache by all parameter values, set the attribute to *.
VaryByControl
A semicolon-separated list of strings used to vary a user control's output cache. These strings represent the ID property values of ASP.NET server controls declared in the user control. For more information, see Caching Portions of an ASP.NET Page.
Note This attribute is required in a user control @ OutputCache directive unless you have included a VaryByParam attribute. This attribute is not supported for @ OutputCache directives in ASP.NET pages.
Remarks
Setting values for the page output cache is the same as manipulating the HttpCachePolicy.SetExpires and HttpCachePolicy.SetCacheability methods through the HttpResponse.Cache property. Setting the VaryByParam attribute when creating a user control implements partial-page caching for that control.
If a Web Forms page requires authorization to be viewed by a user, the output cache sets the Cache-Control HTTP header to private. For more information on all these subjects, see Caching ASP.NET Pages.
If you set the Shared attribute to true, cached user control output can be accessed by multiple Web Forms pages. If you do not set it to true, the default behavior is to cache one version of user control output for each page that contains that user control. You can potentially save a significant amount of memory by enabling the Shared attribute. For more information, see Caching Portions of an ASP.NET Page.
Example
The following example demonstrates how you can set the duration that a page or user control is output cached.

The next example demonstrates how you can instruct the output cache to cache a page or user control by the location and count form parameters from a form's POST or from a query string. Each HTTP request that arrives with a different location or count parameter (or both) is cached for ten seconds. Any subsequent requests with the same parameter values are satisfied from the cache until the entry expires.


@ Reference
Declaratively indicates that another user control or page source file should be dynamically compiled and linked against the page in which this directive is declared.

Attributes
Page
The Web Forms page that ASP.NET should dynamically compile and link the current page against at run time.
Control
User control that ASP.NET should dynamically compile and link the current page against at run time.
Remarks
Using this directive allows you to dynamically compile a user control and add it to the ControlCollection object, accessed through the Controls property, for the page or server control. This allows you to cast the returned type after you have called the LoadControl method (inherited by the page from the TemplateControl class).
Example
The following example demonstrates using this directive to link a user control, MyControl.ascx, and load it to a containing page using the LoadControl method. When it is loaded to the page, the user control's MyProperty value is set, and the user control is added to a PlaceHolder server control's ControlCollection object through the Controls property.
[C#]








[Visual Basic]

Upgrading VS 2003 Web Projects to be VS 2005 Web Application Projects

Step 0: Install the VS 2005 Web Application Project Preview

VS 2005 Web Application Project support is not built-into the shipping VS 2005 (although it will be included with the SP1 release). So the first step (if you haven't done it already) is to install it.
You can learn more about it and install the release candidate build from here. After installing it, please spend a few minutes following the tutorials on this site to test it out and learn the basics of how it works.

Step 1: Backup Your VS 2003 Projects

Please make sure to save a backup of your VS 2003 Web Projects and Solutions before attempting any of the below steps. There is the chance that you might need to roll-back to the VS 2003 solution if you run into issues, or start over from any step.

Step 2: Copy Remote Frontpage Projects to your local machine

If you use Frontpage Server Extensions to access your project on a remote server, you will need to copy it locally before migration (if your web projects run locally then you can skip this step). VS 2005 Web Application Projects do not support accessing projects remotly via the Frontpage Server Extensions. If you do not copy the project locally first, migration will convert the project to a VS 2005 Web Site project instead.
To copy the remote site locally use the VS 2003 Copy Project menu command under the project menu. This will lauch the copy project dialog.

Change the destination to "http://localhost/ProjectName" and be sure to select "All project files".
After the project has been copied locally you should remove the remote one from the solution and use "Add Existing Project" navigating to the c:\inetpub\wwwroot\VS03Web folder where your project was copied.

Make sure the project still builds in the IDE.

Step 3: Open Your VS 2003 Web Project and Make Sure it Compiles Clean

Before attempting to migrate anything, please make sure that you open up your existing VS 2003 solution and perform a clean-re-compile of the entire solution -- and then run the application. Spending 2 minutes to verify everything is working before you migrate can save a lot of grief later (especially if the cause is because of a last-minute directory move, etc).

Step 4: Temporarily remove the VS 2003 Solution from Source Control

If your project is currently under source control, you should temporarily remove/unbind it from source control prior to converting it. Once converted, you can then add it back under source control.

Step 5: Open the solution or project in VS 2005 and perform a project migration

Close the solution in VS 2003, and start VS 2005. Choose "File->Open Project" from the File menu, and select the .sln or .csproj file for the solution you wish to migrate. This will cause the VS 2005 Migration Wizard dialog to launch:

Choose a location to backup the project:

The conversion wizard will then perform a few steps:
1) Update the project file to be a VS 2005 MSBuild based project file
2) Add an xhtmlcompliance section within your web.config file to enable "legacy" html rendering
3) Update your web project to go directly against IIS instead of use FrontPage Server Extensions
4) Fixup any language changes between .NET 1.1 and .NET 2.0

When complete, the solution will open up within VS 2005:

Step 6: Compiling and Running your Web Project

You are now ready to compile your web project. Choose "Build->Build Solution" or Ctrl-Shift-B to do this.
The most common issue I've seen people run into at this stage are compile conflicts with new class names introduced with V2.0. For example: ASP.NET now has a built-in menu and treview control (as well as built-in profile, membership and rolemanagent APIs) -- so if you declare these types in your VS 2003 web projects today you may get an "ambiguous type" compiler error when you compile (note: the compiler lists each line and typename for you). If this happens, you should update your declarations to fully qualify the TreeView/Menu/Etc. you want to use (for example: change "TreeView" to "MyCompany.MyControls.TreeView").
You may or may not also run into some API changes when moving to V2. This site lists the known set of breaking API or functionality changes that were made between V1.1 and V2.0. You should consult this if you run into a problem.
Once your project is compiling clean, you should be able to run and debug in on IIS using ASP.NET 2.0.

Step 7: Run the Web Application

Run the application to verify that the application is working fine. Fix up any runtime issues that you find. This site lists the known set of breaking API or functionality changes that were made between V1.1 and V2.0, and will be able to help if you run into any issues.

Step 8: Convert to Partial Classes

When you migrate your project using the above steps, none of your code-behind page code or classes are modified. This means that the code should look (and work) just like it did in VS 2003. This makes it much easier to migrate existing code to VS 2005.
You can optionally choose to keep your code in this format. Doing so will require you to manually update the control field declarations within your code-behind file -- but everything else will work just fine in VS 2005.
Alternatively, you can update your pages/controls to use the new partial-class support in VS 2005 to more cleanly organize the tool-generated code from your code-behind logic. This is done by separating out your current code-behind files into two separate files -- one for your code and event handlers, and the other a .designer.cs file that contains the control field declarations for the code-behind. Please review this tutorial for more details on how this new code-behind model works.
To migrate your code to use this new model you should follow these two steps:
1) Make sure your web project is compiling clean without errors. You want to make sure that all code is compiling clean without problems before attempting to update it to use partial classes. Please test this before proceeding.
2) Right click on the root web project node within the solution explorer and choose the "Convert to Web Application" menu item. This will then iterate through each page or user control within your project and migrate all control declarations to be declared within the .designer.cs file, and event handlers to be declaratively specified on the controls in the .aspx markup.

You should then do a clean re-build of your web solution. This should hopefully compile clean without errors (the cases where I've seen errors are situations where you've done custom modification of the control declarations within your code-behind class, and the upgrade wizard mishandles them). If you have any errors in your task list, you can navigate to the appropriate page in the solution explorer and choose the "View Code" and "View CodeGen" context menu items to examine the code and fix any issues.
If for some reason the .designer.cs file doesn't have a control declaration added, you can manually declare it within the code-behind file of the page (just like you would in VS 2003). One issue we've sometimes seen reported are cases where a developer has specifically overriden the type of a Usercontrol declaration in a VS 2003 code-behind file (for example: MyControl1 instead of the generic UserControl base class), and the type isn't correctly transferred to the .designer.cs file (producing a compile error). If the correct user-control type declaration isn't added to the .designer.cs file, you can optionally just delete it from the .designer.cs and add it the code-behind file of the page instead. VS 2005 will then avoid re-adding it to the .designer.cs file (it first looks in the code-behind file for declarations before updating the .designer.cs file on changes).
Note: as an advanced option, you can also upgrade each page on a page-by-page basis (just right-click on the page and choose the "Convert to Web Application" option on it). You might consider doing this if you want to watch closely the changes made on each page.

Why Create a User-Control Library

Adding a user-control into an existing web application project is very easy. Simply right-click on the project and choose the "Add New Item" menu item and pick the "Web User Control" template.

What this tutorial will cover is how you can also use VS 2005 Web Application projects to create re-usable libraries of user-controls that are potentially referenced and pulled-in from multiple web projects. This provides additional re-use flexibility with large-scale web-projects, and with VS 2005 Web Application Projects is now easier than it was with VS 2003.

Create a New User Control Library Project

Select File->Add New Project to add a new project to your existing VS Solution. Name the new project "MyUsercontrolLibrary" and make it a VS 2005 Web Application Project:

Create it as a peer-directory of the "MyWebProject" project we've been working on - with both project sub-directories stored immediately below the .sln file (note: this isn't a requirement, but can make things easier to manage):

Delete the Default.aspx and Web.config files that are added to new projects by default, and then right-click and add a new user-control to the MyUserControlLibrary project (name it "samplecontrol.ascx"):

Your solution explorer will then look like:

Open up the SampleControl.ascx file, and add two textbox controls, a button, and a label into the user-control:

Then create and add a button event-handler to the User-control code-behind file:

Choose Build->Build Solution or hit Ctrl-Shift-B to build the solution and verify there are no errors. You now have a user-control library that you can update and maintain as a separate project. You can add any user-control files, standalone classes, master-pages, or pages in it that you'd like.

Consuming User Control Libraries

There are a couple of different strategies that can be used when consuming user-control library projects. Often you will have a separate solution for managing these projects, and then make a file-based assembly reference to them from your web-project. For this sample, though, we will simply use a project-to-project reference.

Within your "MyWebProject" project (which is the web app), right-click on the References node and select "Add Reference". Click on the "Projects" tab and select the "MyUsercontrollibrary" project. This will copy and reference the assembly with all the code for our control library.

Then right-click on your root project node, and choose the "Add->New Folder" command. Create an empty directory called "UserControls".

Right-click on the "MyWebProject" project node and pull up the properties for the project. Select the "Build-Events" tab so that we can configure a pre-build event on the project:

In the pre-build event command-line field enter this command:

copy $(SolutionDir)\MyUserControlLibrary\*.ascx $(ProjectDir)\UserControls\

This will copy the .ascx files from the UserControlLibrary into the \UserControls\ sub-directory of the web-application before each build of the project. Choose Build->Build Solution or press Ctrl-Shift-B to build the solution and the project. Notice that when you run the above command, it will copy the .ascx files into the project's usercontrols sub-directory, but not add the .ascx files themselves into the project. This means that they can be easily excluded from source-control for the project.

To see this in action, compare the results of the solution explorer in normal mode:

and then when the "Show All Files" button is clicked (notice that files not part of the project are white):

To use this new user-control, create a new page called "UserControlSample.aspx" in your web application project. Have it use the Site.Master master-page we created earlier, and then register and use the user-control .ascx file:

User-controls in VS 2005 are also now supported in WYSIWYG mode. So if you click the "design" tab of the .aspx page, you will see the user-control rendered correctly (instead of the grey-box that was displayed in WYSIWYG mode for user-controls in VS 2003):

Right-click on the "UserControlsSample.aspx" file in the Solution Explorer and select the "Set as Start Page" context menu-item. Then press either F5 or Ctrl-F5 to build and run the web-application:

You can now make any changes you want to the User-Control library (including adding new user-controls and classes). The consuming web-project will then be kept up-to-date on each build of the solution.

Add a Master Page to the Web Project

Right-click on the project and select Add->Add New Item to add a new MasterPage called "Site.Master" to the project:

This will then create a default master page template that you can edit either in WYSIWYG design-mode or in HTML source mode:

Modify the Site.Master content to have a logo at the top, and then use a table to (or divs with CSS) to create a two column layout in the page. Place the control with the ID of "MainContent" in the second column, and leave the first column for a menu we'll add later in this tutorial.

If you switch into WYSIWYG design mode the Site.Master will look like this:

Now we are ready to have pages in our site pick up and use the master-page file.

Update Default.aspx and DataSample.aspx to use the Master Page

Open the default.aspx page we built in an earlier tutorial, and switch to HTML source-view. To update it to use the master-page go to the top <%@ Page %> directive and add a "MasterPageFile" attribute:

Note that VS 2005 will provide intellisense completion for both the attribute name, as well as provide a list of all valid master-pages in the project that you can use. Select the new "Site.Master" file that we just created.

Then delete the static html previously on the page, and add an control to the page with an id of "content1". Note that VS 2005 will provide intellisense on all of the valid contentplaceholders within the Site.Master file that you can override:

Wrap all previous content on the page with the control:

Click on the "design" tab to switch into WYSIWYG mode. You'll then see the default.aspx page inside the Master Page:

Select the Default.aspx page in the Solution Explorer and set it as the startup page (right-click and choose "Set as Startup Page"). Then press F5 (or ctrl-F5) to run it.

Now repeat the above process for the DataSample.aspx page as well:

Add a Web.SiteMap to the Web Project

Right-click on the project and select Add->Add New Item to add a new Site Map file called "Web.SiteMap" to the project:

Edit the new web.sitemap file to have the below three nodes within the site-map (a root node for the home page, a sub-node for the data page we built, and another sub-node for a future page we are going to build in the next tutorial section):

Open the Site.Master page up again and switch to design-mode. Delete the "todo: menu" comment in the left-most column, and then drag/drop the "Treeview" control from the "navigation" section of the Toolbox in VS:

Select a New Datasource from the drop-down list above, and choose the "Site Map" datasource:

This will then data-bind the Treeview against the web.sitemap file we created above. Choose the auto-format menu item in the "common tasks" menu and format it as "simple":

Note how the tree-view menu shows the current web.sitemap's hierarchy at design-time.

Press the F5 or Ctrl-F5 key to build and run the site:

Notice how the tree-view menu automatically highlights (by underlining - although you can style it however you want) the current node in the site-hierarchy as a user navigates around the site.

Adding Classes to the Web Project

In this sample we'll be data-binding a GridView control on a page to a set of classes in our web application project.

To begin, right-click on the project and select Add->Add New Item to add a new class called "Author" to the project:

Note that classes can be added into any directory of the web project. There is no requirement that they live under the /app_code directory.

Make the new Author class public and then add some properties and constructors to it:

Then add a new class file called "Publisher.cs" to the project and have it implement a method called "GetAuthorsByState":

Note that the above method uses Generics (a new feature in V2.0) to return a strongly typed List collection of type "Author".

Choose either the "Build->Build Solution" menu item or choose "Ctrl-Shift-B" to build the project. You now have a set of classes you can use to databind against.

Building a Data-Bound ASP.NET Page

Right-click on the project and select Add->Add New Item to add a new ASP.NET Page called "DataSample.aspx" to the project:

Switch to design-view on the newly created DataSample.aspx page, add a simple page title, a search Textbox called "TextBox1", a button, and then drag/drop a GridView control from the "Data" section of the Toolbox:

Select "New DataSource" from the drop-downlist in the "Common Tasks" smart-tag menu. Select "Object" as the data-source you want to bind-to. This will then bring up a wizard that lists all classes in your project:

Select the "MyWebProject.Publisher" class, and then hit next. Then choose the "GetAuthorsByState" method as the method to bind against:

Choose to bind the "state" parameter of the "GetAuthorsByState" method to the TextBox1 on the page (note: change the parameter source to "control" to get this listing):

When you click "finish" the GridView columns will be updated to reflect the public properties in your Author class. Choose the "Auto format" task on the GridView control to make it look a little better:

To test the page, select the DataSample.aspx page in the solution explorer, right click, and then select the "Set as Start Page" context menu item. Then hit F5 (or ctrl-f5) to build, run and debug. When you add "wa" as the state parameter you'll get a list of authors:

Coding against controls in our Default.aspx page

In the first Hello World Tutorial we edited the Default.aspx page that is added automatically when we create a new VS 2005 Web Application project.

Specifically we added an and control to the page:

You can then program against these controls using your event-handlers within the code-behind file. For example:

You can then set a breakpoint (press the F9 key on the line to set it on), and then hit F5 to compile, run and debug the page:

Handling server events from controls in our .aspx page

To handle a server event from a control on your page, you can either manually add an event-handler to the control yourself (by overridng the OnInit method in your code-behind class and adding the event delegate there), or by using the WYSIWYG designer to generate an event handler.

To use the WYSIWYG designer, click on the "design" tab of the .aspx page to bring up the design-surface. If you want to add the "default" event for the control, you can simply double-click on the control to generate an event handler for it (this is useful for things like buttons, etc). Alternatively, you can select the control on the design-surface and click on the "events" tab of the property-grid. This will then list the events that are available to handle:

You can double-click on any of the events to automatically add a default named event handler. Alternatively, you can type the name of the event handler you wish to generate.

You can then add whatever code you want within the code-behind file:

Press F5 (or Ctrl-F5) to build and run the project. Now, when a user selects a date in the calendar, the selected date will be output using the Label control: