Recipe 1.19: Adding a Totals Row to a DataGrid

Problem

Related Reading ASP.NET Cookbook The Ultimate ASP.NET Code Sourcebook By Michael A. Kittel, Geoffrey T. LeBlond

You have a DataGrid containing numeric information and you need to display a total of the data in the last row of the grid.

Solution

Enable the output of the footer in the DataGrid, accumulate the total for the data in the ItemDataBound event handler, and then output the total in the DataGrid footer.

In the .aspx file, set the ShowFooter attribute of the asp:DataGrid element to True.

In the code-behind class for the page, use the .NET language of your choice to:

1. Initialize the totals to 0, and then bind the data to the DataGrid in the normal fashion.

2. In the ItemDataBound event handler, add the values for each data row to the accumulated totals.

3. In the ItemDataBound event handler, set the total values in the footer when the footer is data bound.

Figure 1-24 shows some typical output. Examples Example 1-57 through Example 1-59 show the .aspx file and code-behind files for an application that produces this output.

Discussion

The best way to describe the addition of a totals row to a DataGrid is by example. In this recipe, you'll want to create the DataGrid a little differently than normal. In the asp:DataGrid element, set the ShowFooter attribute to True to cause a footer to be output when the control is rendered. You then place the totals data in the footer.

<asp:DataGrid 
  id="dgBooks" 
  runat="server" 
  BorderColor="000080" 
  BorderWidth="2px"
  AutoGenerateColumns="False"
  width="100%"
  
ShowFooter="True">

Next, add a FooterStyle element to format all of the columns in the footer with a stylesheet class, background color, and horizontal alignment:

<FooterStyle cssClass="TableCellNormal" HorizontalAlign="Right" 
             BackColor="#C0C0C0" />

All columns are defined in the Columns element as asp:TemplateColumn columns. This provides a lot of flexibility in the display of the columns. The first column contains only an ItemTemplate that is bound to the Title field in the DataSet. The FooterText property of this column is set to "Total:" to simply display the label for the other values in the footer.

<asp:TemplateColumn HeaderText="Title" 
FooterText="Total:"> 
  <ItemTemplate>
    <%# DataBinder.Eval(Container.DataItem, _
                        "Title") %>
  </ItemTemplate>
</asp:TemplateColumn>

The second and third columns contain an ItemTemplate element to define the format of the data placed in the rows of the grid and a FooterTemplate element to define the format of the data placed in the footer of the respective columns:

<asp:TemplateColumn HeaderText="List Price" 
                    ItemStyle-HorizontalAlign="Right">
  <ItemTemplate>
    <asp:Literal id="lblListPrice" runat="server" 
                 text='<%# DataBinder.Eval(Container.DataItem, _
                                           "ListPrice") %>' />
  </ItemTemplate>
  <FooterTemplate>
    <asp:Literal id="lblListPriceTotal" runat="server" />
  </FooterTemplate>
</asp:TemplateColumn>

In the code-behind, two private variables (mListPriceTotal and mDiscountedPriceTotal) are declared at the class level to store the accumulated sum for each of the price columns. The bindData method is identical to previous recipes, except for the addition of the code to set mListPriceTotal and mDiscountedPriceTotal to zero before the data binding is performed.

The ItemDataBound event is used to accumulate the sum of the prices as the rows in the DataGrid are bound. You can do this because the data binding always starts at the top of the grid and ends at the bottom. Because the ItemDataBound event method is called for every row in the grid, you must first determine what row this event applies to by checking the ItemType of the passed event arguments. Several groups of item types are needed here, so a Select Case statement (switch in C#) is used.

When the item type is a data row, you need to get the values in the list price and discounted price columns, and then add them to the appropriate total variables. Getting the price values requires getting the price values from the data passed to the method (e.Item.ItemData), adding the price data to the totals, getting a reference to the controls used to display the data, and then setting the price value in the controls for the row. Getting a reference to the control is the trickiest part. The easiest and most flexible approach is to use Literal controls in the ItemTemplates of the DataGrid defined in the .aspx file. By setting the IDs of the literal controls, the FindControl method of the row being data bound can be used to get a reference to the desired control.

TIP: If the IDs of the controls in the ItemTemplates are not defined, the only way to get a reference to a control is to index into the cells and controls collections of the row. In this example, the list price control is in the second column of the grid. Cells in a DataGrid are created with a literal control before and after the controls you define in a column; therefore, the list price control is the second control in the controls collection of the cell. Getting a reference to the list price control using this method would be done with listPriceControl = e.Item.Cells(1).controls(1). This approach is very dependent on column layout—rearranging columns would break code that uses this approach. The FindControl method is much easier to maintain and less likely to be broken by changing the user interface.

TIP: Literal controls are used in this example because they are rendered without the addition of other controls and because accessing the price value is as simple as getting the value of the text property of the control. An asp:Label control would seem like a good option here; however, it is created as three literal controls in the DataGrid, making it necessary to index into the controls collection of the control returned by the FindControl method to get the needed price value.

When the item is the footer, all data rows have been processed and you have the totals for the price columns in the mListPriceTotal and mDiscountedPriceTotal variables. Now you need to output these totals in the controls placed in the footer. This is done by again using the FindControl method of the passed item to get a reference to the controls in the footer. After a reference to the control is obtained, the text property is set to the total for the column. In our example, the totals are also being formatted to be displayed in currency format with two decimal places.

Recipe 4.4: Communicating Between User Controls

Problem

You have multiple user controls on a page, and one of the user controls needs to send data to another as, for example, when one control takes its form or content from the user's action on another.

Solution

Create a source user control, a destination user control, and a web form that contains both user controls. (See Recipe 4.1 and Recipe 4.2 for detailed steps.) In the source user control, create a custom event and raise the event when the required action is performed, such as when a user completes her entry for a form. In the destination user control, create an event handler to receive the event from the source user control. Finally, "wire" the event raised in the source user control to the event handler in the destination user control in the Page_Load event of the web form. The output of a test page showing one user control communicating with another appears in Figure 4-4. The code for our example application that implements the solution is shown in Examples Example 4-15 through Example 4-23. Example 4-15 shows the .ascx file for the source user control. Example 4-16 and Example 4-17 show the VB and C# code-behind for the source user control. Example 4-18 shows the .ascx file for the destination user control. Example 4-19 and Example 4-20 show the VB and C# code-behind for the destination user control. Example 4-21 shows the .aspx file for the web form used to demonstrate the user controls and their interconnection. Example 4-22 and Example 4-23 show the VB and C# code-behind for the demonstration web form.

Discussion

Rather than focus on the basic content and creation of user controls, which is the focus of the previous recipes in the chapter, this recipe instead focuses on the interaction between user controls. The approach we advocate for handling this interaction involves creating a custom event for the source user control and raising the event when the communication is to be initiated, such as when the user clicks a button to complete his entry for the form. In order to receive the event from the source user control, the destination user control must have an event handler tailored for that purpose.

In our approach, creating the custom event for the source user control involves creating a custom event argument class, which provides the ability to add a message to the event arguments. It also involves using a delegate, which is a convenient way to pass to the destination user control a reference to an event handler for the OnSend event raised by the source user control.

We've created an application to illustrate our approach. Because of the unusually high number of interrelated files, this example may appear a bit overwhelming at first, but it is actually pretty straightforward. Keep in mind that there are three basic pieces:

• A user control that sends a message (the source)

• A user control that receives the message (the destination)

• A web form that contains the two user controls and wires them together

The source user control contains only a button that is used to initiate sending a message.

The source user control code-behind contains the bulk of the code. First, we create a custom event argument class to provide the ability to add the message to the event arguments. This class inherits from System.EventArgs and adds a message property, as shown in Example 4-16 (VB) and Example 4-17 (C#).

Next, we define a new delegate signature, customMessageHandler, to allow the MessageEventArgs object to be passed as the event arguments. Without this delegate, you would have to use the EventArgs object, which does not provide the ability to pass custom information. An event is then defined with this type of delegate.

TIP: A delegate is a class that can hold a reference to a method. A delegate class has a signature, and it can only hold references to methods that match its signature. The delegate object is passed to code that calls the referenced method, without having to know at compile time which method will actually be invoked. The most common example is building a generic sort routine, one that allows you to sort any type of data, where you pass to it not only the data to be sorted but also a reference to the comparison routine needed to compare the particular data. The situation here is somewhat similar. In this case, we are passing a message to the destination user control (contained within an instance of MessageEventArgs) as well as a reference to an event handler for the OnSend event raised by the source user control. A delegate provides the best, most convenient way to accomplish this.

Our remaining task in the source user control code-behind is to provide a standard event handler for the send message button click event. In this handler, an instance of MessageEventArgs is created and populated with the message being sent. The OnSend event is then raised, passing a reference to the source user control as the event source and a reference to the messageArgs object containing the message being sent. In our example, this is a simple hardwired message, but it demonstrates the basic principal.

WARNING In C#, the OnSend event must be checked to make sure it is not null before raising the event. Failure to do so will result in an exception being thrown if no handler is wired to the event. This is not required for VB.

Our example's destination user control, which is shown in Example 4-18, contains only a label used to display the message sent from the source user control.

The destination user control code-behind, which is shown in VB in Example 4-19 and in C# in Example 4-20, contains a single method to handle the event raised from the source user control. The signature of the method must match the customMessageHandler delegate defined in the source user control. The only operation performed is to update the label in the user control with the message passed in the event arguments.

In our example, the .aspx file for the web form used to demonstrate the user controls, which appears in Example 4-21, registers the two user controls and instantiates each of the controls.

The code-behind for the demonstration web form, which is shown in VB in Example 4-22 and in C# in Example 4-23, provides the glue for tying the event from the source user control to the destination user control. This is done by adding the updateLabel of the destination user control as an event handler for the OnSend event raised by the source user control. What we're actually doing here is adding a delegate to the source user control's OnSend event's event handler list; that list now consists of just one event handler, but can include more.

TIP: Event delegates in .NET are multicast, which allows them to hold references to more than one event handler. This provides the ability for one event to be processed by multiple event handlers. You can try it yourself by adding a label to the demonstration web form, adding a new event handler in the web form, and then adding your new event handler to the OnSend event's event handler list. This will cause the label on the destination user control and the web form to be updated with the message from the source user control. An example that does this with multiple user controls is shown in Recipe 4.5.

WARNING In VB, when using the event/delegate model, the keyword WithEvents is not used. (Recall that the WithEvents keyword indicates that a declared object variable refers to a class instance that can raise events.) WithEvents and the event/delegate model can be intermixed, but they should not be used for the same event.

See Also

Programming C# or Programming Visual Basic .NET, both by Jesse Liberty (O'Reilly), for more about delegates

Recipe 7.4: Displaying User-Friendly Error Messages

Problem

You want the event-handling methods described in this chapter to write detailed messages to an error log for use in debugging your application, but you want to display friendly, informative messages to the user.

Solution

Create a custom exception class that includes a property to hold the user-friendly message, and then, when an error occurs, instantiate a new exception object of the custom type in the Catch block of your error-handling code, set the property of the exception to the desired message, and then throw the new exception.

Use the .NET language of your choice to create the custom exception class by deriving from System.ApplicationException and adding a property to hold the user-friendly message, giving it a name like userFriendlyMessage.

In the code-behind for the ASP.NET pages of your application that need to perform error handling, use the .NET language of your choice to:

1. In the Catch block of methods where informative messages are useful, instantiate a new exception object of your custom class type, set the userFriendlyMessage property to the desired message, and then throw the new exception.

2. In the Application_Error event handler, write the detailed information provided by the exception object to the event log and then display the message contained in the userFriendlyMessage property of the exception on a common error message page.

The custom exception class we've created to demonstrate this solution is shown in Example 7-10 (VB) and Example 7-11 (C#). The code showing how to create the new exception is shown in Example 7-12 (VB) and Example 7-13 (C#). The code for the Application_Error event handler is shown in Example 7-14 (VB) and Example 7-15 (C#). (Because the .aspx file for this example contains nothing related to the error handling, it is not included in this recipe.)

Discussion

The first step to providing user-friendly messages with your exceptions is to create a new class that inherits from System.ApplicationException. (The System.ApplicationException class extends System.Exception but adds no new functionality. It is meant to be used to differentiate between exceptions defined by applications and those defined by the system.) You then need to add a property to the class to support the user-friendly message. The last step in creating the new exception class is to create a constructor that will create the base exception, by calling the base class constructor with the raw message and a reference to the inner exception, and then set the user-friendly message. Example 7-10 (VB) and Example 7-11 (C#) show how we have implemented these steps.

The new exception class is put to use in the Catch block of your code by creating an instance of the new exception class, passing it the original message, a reference to the exception, and the desired user-friendly message. The reference to the original exception is passed to preserve the linked list of exceptions. In this case, your new exception will point to the original exception by using the inner property of the new exception. After the new exception class is created, it is then thrown. Example 7-12 (VB) and Example 7-13 (C#) illustrate a sample Catch block.

As shown in Example 7-14 (VB) and Example 7-15 (C#), our sample Application_Error event handler writes detailed information to the event log and then displays the message contained in the userFriendlyMessage property of the exception. This example event code is actually a variation of the event code described in Recipe 7.3, modified to check whether the exception being processed has a user-friendly message to use instead of the raw exception message.

This recipe's approach can be extended many ways to suite your needs. For example, the custom exception class could contain a "nextPage" property that could be set to pass information on where the user should be taken after reviewing the error message.

See Also

Recipe 7.3