.NET news » ASP.NET

The DropDownList serves as an ideal user interface element for master/detail reports where there is a one-to-many relationship between the master and detail records.

A common type of report is the master/detail report, in which the report begins by showing some set of "master" records. The user can then drill down into one of the master records, thereby viewing that master record's "details." Master/detail reports are an ideal choice for visualizing one-to-many relationships, such as a report showing all of the categories and then allowing a user to select a particular category and display its associated products. Additionally, master/detail reports are useful for displaying detailed information from particularly "wide" tables (ones that have a lot of columns). For example, the "master" level of a master/detail report might show just the product name and unit price of the products in the database, and drilling down into a particular product would show the additional product fields (category, supplier, quantity per unit, and so on).

There are many ways with which a master/detail report can be implemented. Over this and the next three tutorials we'll look at a variety of master/detail reports. In this tutorial we'll see how to display the master records in a DropDownList control and the details of the selected list item in a GridView. In particular, this tutorial's master/detail report will list category and product information.

Explains how to send e-mail from ASP.NET, including sending of simple e-mail, adding attachment, HTML e-mails and how to avoid potentially dangerous request errors.

ASP.NET server library for creating CMS website (forums, articles/wiki, news, users/roles, ...), using NHibernate for data access

Embed PDFs into a Web Page with a Custom Control

Creating Tab control in ASP.NET

How to create a DotNetNuke® module using Visual Studio Express - for DotNetNuke version 4.

Explore ways to reduce page load time, manage state efficiently, scale back on memory use, handle resources better, and improve data access in your ASP.NET applications.

How to create a DotNetNuke Module that does something and understand how it and the DNN architecture work together

Page state, commonly referred to as view state, is persisted in a hidden form field, by default. When a page is being rendered, any programmatic changes to a control's state is saved to the page's overall view state. During the rendering stage, this view state is serialized into a base-64 encoded hidden form field and sent down to the client's browser. On postback, the view state data is sent back to the web server, where it is deserialized and returned to the appropriate Web controls in control hierarchy so that they may re-establish their state as it was prior to the postback.

View state provides a slick way to remember state in a stateless client-server model and it happens underneath the covers without any extra effort from page developers. The downside of view state, however, is that in certain situations the view state can grow to be exceedingly large. A large view state requires a longer page download time since it bloats the total web page size and also affects the postback time, since the entire view state content must be posted back to the web server along with the other form fields.

It is possible, however, to persist view state to an alternate medium. Such customizations were possible in ASP.NET 1.x by overriding a couple of methods in the Page class. ASP.NET 2.0 makes customizing page state persistence easier as this logic is handled through a separate class. In this article we'll explore the built-in page state persistence options in ASP.NET 2.0, which includes the ability to persist page state to session state rather than through a hidden form field.