Depending on the kind of custom data-bound functionality you need to support, inheriting from one of the existing controls in the .NET Framework might be your best option. Specifically, if you want to tailor the presentation of the data in a control, many of the Windows Forms Framework controls expose rich event models and virtual methods in the base class that let you integrate your own code to customize the appearance and/or behavior of the control as it is presented to the user or while they interact with it.

The data-binding behaviors of the Windows Forms controls are pretty tightly woven into the controls; they aren’t exposed in a way that lets you easily override that data-binding behavior by inheriting from the control. If you need to vary the data that gets presented by a Windows Forms control, you are better off doing that by changing the data source that you bind to the control, rather than trying to make the control change what data in the bound data source it presents.

For example, if you wanted to only show selected items in a collection of data within a data-bound control, you could just bind that control to a binding source and use the Filter property on a binding source to modify which data items are presented by the control. Alternatively, you could requery for new data based on the user’s interactions.

However, if you want to customize the appearance of the data within a control, most of the data-bound Windows Forms controls let you take over some or all of the painting or rendering logic of the control and do the data rendering yourself. For text boxes, combo boxes, and the DataGridView, there are ways to handle the painting events that are raised by the Framework, and in your handler you can take over the painting of data yourself. You also have opportunities to customize the formatting of the data as it is rendered by the control. (See the discussion in Chapter 4 of the Format and Parse events of the Binding object, and the description in Chapter 6 of theDataGridView control’s CellFormatting event, and how to use those to modify the data presented within the control to be something different than what it is in the underlying data source.)

Most of these capabilities can be done on a case-by-case basis inside the forms where you use the controls. But many times it will make sense to encapsulate that logic, either to separate it from the other code in your form or to package it for reuse. Deriving a class from one of the Windows Forms control classes is one way to accomplish this encapsulation in an easily reusable way.

As an example of creating a custom data-bound control by deriving a class from an existing Framework control, let’s create a specialized DataGridView control that presents its bound data as grouped data items within each column. For example, say you have a table containing summary data of all the products ordered by each customer by date. Each customer may have multiple orders for the same product, and multiple orders might have been placed by each customer on a given date. If you sort the data by customer and product name, it would be easier to read the data in the grid if the repeated customer names and products weren’t shown in every row of the table. It would be much easier to read if only new values were shown, and rows with the same value as previous rows were presented with blank cells, and the borders of the cells also helped to indicate the grouping of data values (see Figure 8.1).

FIGURE 8.1: GroupByGrid Sample Application

Because this example specifies some behavior and altered rendering of the data in the grid, it makes a decent candidate for subclassing (deriving from) the DataGridView control. To achieve this functionality doesn’t require a ton of code, just a few overrides of base class methods and tapping into the formatting and painting behavior of the base class.

Once you have developed a custom control, you need to add it to a form or another user control to test it and verify that it works as expected. To test this, do the following:

For production purposes, you don’t want others to have access to your projects and source code, so the way to use a custom control library without opening its project in the consuming solution is to customize the Toolbox. To do this, perform the following:

1.   Open a new or existing Windows application project.

2.   Bring up a form in the designer.

3.   Display the Toolbox. From here, there are two ways you can add your custom controls to the Toolbox.

      – You can locate the DLL that contains your custom controls through Windows Explorer and drag and drop the DLL onto the Toolbox. This will add all of the controls in that DLL to the Toolbox.

      – If you want to have more explicit control over which controls are added, right-click in an existing tab within the Toolbox (such as the All Windows Forms tab), or create your own by choosing Add Tab from the context menu, then select Choose Items from the context menu. Click the Browse button in the lower right of the Choose Toolbox Items dialog and navigate to the location of the DLL containing your custom controls. Once you select that file and click Open, the dialog will check the boxes of all custom controls it finds in that library (see Figure 8.2). If you want to exclude certain controls from being added, simply uncheck their boxes. Click OK to add the selected controls to the Toolbox.

FIGURE 8.2: Choose Toolbox Items Dialog

4.   Once the controls are in the Toolbox (see Figure 8.3), you can drag and drop them onto forms and user controls like any other built-in Framework control in the Toolbox.

FIGURE 8.3: Customized Toolbox Tab and Controls

A new capability in Visual Studio 2005 is to run and debug a Windows user control without having to develop a forms application and add it to a form. Visual Studio now includes a test container (see Figure 8.4) for presenting user controls. This lets you test many of their behaviors directly from the Windows Control Library project that they live in. You display this by running a debug session from a project of type Windows Control Library.

FIGURE 8.4: User Control Test Container

The test container renders the user control in a simple host container that exposes the control properties in the container’s properties panel that you can use to tweak properties and verify that they work correctly. Unfortunately, for data-bound controls, the control’s key behaviors are all based around providing runtime data through a data source. Although those properties are exposed in the test container (like they are in the designer for a hosting form), there is no data available in the test container’s runtime context to bind the control to. So for most data-bound control testing, you still need to create a test application form to host the control in and provide it with some data to bind to. But if you just want to test the way certain parts of your control will render themselves, the test container can be a quick way to check that out.

As mentioned earlier, the problem with deriving a new control from an existing Framework control type is that if you access or override any protected members of the base class, you need to have a great deal of insight into what the side effects will be. The public members exposed by a control are a lot easier to understand, are better documented, and provide greater protection from introducing unexpected side effects. As a result, you’ll usually have better success customizing the behavior of Framework data-bound controls from the outside through their public members rather than from the inside through their protected members.

However, if there are particular customizations you need to make that will be used in more than one location, repeating those customizations in all the forms that use the control is tedious, error-prone, and introduces an unnecessary maintenance burden. To avoid this repetition, you can customize the built-in Framework controls through containment in user controls. This lets you encapsulate all the customizations inside your user control, so that users of your control don’t have to worry about the messy implementation details at all. They just focus on the (often simplified) API of your control and add it to as many forms as they like.

Your user control can contain a collection of Framework controls, custom controls, and custom code to integrate those controls. You expose public properties and methods on your user control to enable users of your control to code against it in a fashion similar to the Framework controls. Another advantage of taking this approach is that you can use the new BindingSource component to greatly simplify exposing data-binding capabilities from your custom control. By containing a BindingSource (or several) inside your user control, you can easily hook up external data sources passed in by the users of your custom control, yet still have the built-in mechanisms of the Framework controls and components do all the dirty work for you.

The following sections develop a custom data-bound user control to demonstrate these concepts and techniques.

Assume that you need a DataGridView control in several places in your application that is going to present tabular data coming from various data sources. Once the grid is data bound, you want users to be able to input filter conditions into a text box and have it autocomplete the filter text based on the contents of a specified filter field within the table. This kind of grouping of functionality is a good example of where creating a custom user control is a perfect choice. You can reap the benefits of a good design-time experience in laying out the controls and setting their properties in the user control designer, and then you can add it to a form and test it out. Once it is all coded and working correctly, other developers can just add your control to their forms, set a few properties, and have a rich, consistent use case implemented in many places. Figure 8.5 shows the filtered grid in action, and Figure 8.6 shows the autocomplete functionality helping in the selection of filter criteria.

FIGURE 8.5: Filtered Grid in Action

FIGURE 8.6: Filter Textbox Autocomplete

To get this kind of scenario working correctly requires a good understanding of binding sources and grids, as well as control and data-binding lifecycles. You also need to understand other Windows Forms concepts like working with ComboBox controls and using autocomplete functionality on a text box. I’ll step through all of this in the following sections. If you want to follow along to create a control like this, you need to create a Windows Control Library project. This is really a class library project that has references added to it for the System.Windows.Forms and System.Drawing namespaces. The project wizard also adds a blank user control named UserControl1 to the project. You can either rename that to get started, or delete it and add a new user control named what you want. (To add one, right-click on the project and choose Add > User Control.)

At this point, all the code is being injected into the designer code partial class (FilteredGrid.Designer.cs), which is hidden from you in Solution Explorer by default. If you go to Code view on the FilteredGrid control now, you should just see the partial class definition with a call to the InitializeComponent method (which is in the designer partial class file):

This procedure will add the functionality to the control incrementally, just like you normally should while developing such a control. Let’s start with the simplest part—letting users of your control provide a data source and data member to bind the contained grid to a set of data. Because the DataGridView control is a child control of your user control, it is declared as a private member of your user control class. This is true for any controls you drag onto the designer surface of a form or control by default. You can alter this through the Modifiers property in the Properties window, if desired, or by editing the designer-generated code directly. In general, you should avoid directly modifying designer-generated code because your changes can be overwritten by subsequent designer actions, which is why it is all placed in a separate partial class code file in Visual Studio 2005.

One way to support data-binding to the grid in your user control would be to simply allow users to access the contained grid directly and set its data source. This wouldn’t work well for the filtered grid requirements though, because the whole point is to create a control that modifies what is bound to the grid based on input from the filter text box and field list. So the right way to set up data binding in this case is to mimic the data-binding API exposed by other data-bound controls on your custom user control. For displaying tabular data, that means exposing DataSource and DataMember properties that can be set to establish the data binding on your control.

Thanks to the contained binding source component in your control, you won’t have to do any grunt work for the data-binding yourself—you can just delegate the data binding to the binding source, and let it handle the dirty work. Continuing from the procedure in the last section, do the following:

If you tried to set up the data binding through the designer instead of doing it programmatically, you would run into a few problems. First, if you tried to drag the Customers table from the Data Sources window, you would see that it wouldn’t consider the FilteredGrid control a valid drop target for the data source. Second, if you went to the Properties window with the FilteredGrid control selected in the designer, you would see the DataSource and DataMember properties exposed there, but the DataSource property would be grayed out because it is declared as an object reference type, so the designer doesn’t know enough to let you select something as a data source.

You want your DataSource and DataMember properties to behave just like those of the built-in Windows Forms controls, letting you select data sources and members using the graphical pop-up windows that allow browsing of project data sources, as described in Chapter 5. To do this, you need to adorn these properties with some attributes that let the designer know how to treat them in the designer.

Just by adding these attributes and rebuilding the control library, now when you work with the FilteredGrid control in a form’s designer, you get the same drag-and-drop data-binding experience as you do for a DataGridView, ComboBox, or any of the other data-bound Framework controls, as shown in Figure 8.7. You may need to close and reopen the form you are editing the FilterGrid on after rebuilding the solution to see the Properties window changes.

FIGURE 8.7: Setting DataSource and DataMember Properties on the FilteredGrid Control

This gets you the interaction you are looking for in the Properties window, but if you try to drag and drop a data source from the Data Sources window, you will still get a mouse cursor indicating the drop is not allowed (circle with a slash). To remedy this, you need to add an appropriate binding attribute to the class itself.

When you want the designer to be able to set up data bindings for your control through drag-and-drop operations, the designer needs to know whether your control is designed for simple or complex data binding and which properties on the control it is supposed to be setting in response to drag-and-drop operations. To identify these items on a custom control that you want to use through the Data Sources window, you have to add an appropriate attribute to the control class definition so that the Data Sources window can work with it. The attributes used are described in Table 8.1.

Because your FilteredGrid control represents a complex bound control, you need to add a ComplexBindingProperties attribute to the class itself:

The two parameters of this attribute’s constructor specify the names of the properties for setting the data source and data member, respectively, on the control. I recommend that you stick to the convention of naming these DataSource and DataMember, respectively, which is what is done in the FilteredGrid control.

Now you should be able to drag and drop data sources from the Data Sources window onto the control, and the designer will generate all the appropriate objects (typed data set, table adapter, binding source, and data navigator in the case of a typed data set source) and hook them up to your DataSource and DataMember properties appropriately.

One other thing you should do at this point is to implement the ISupportInitialize interface, defined in the System.ComponentModel namespace.

This interface, as discussed in Chapter 7, lets you defer certain initialization steps until all the dependent properties on your control that might be set through the designer are initialized in a batch and then makes them take effect all at once. This interface is kind of like the IDisposable interface, in that if you create a class that contains disposable objects, you should make your class disposable and delegate to the contained objects in the Dispose method.

If your control contains objects that can be initialized, you should make your control initializable and delegate to the contained initialized objects. To do this, add the ISupportInitialize interface to your class definition, and add implementations of the interface’s methods to your class, delegating to the binding source and grid implementations:

This lets you control the initialization order of the controls, as well as giving you a place to control your own batch initialization if needed. I added a Boolean flag, m_Initializing, to the class as well. This lets you use this as a signal in your methods to indicate when you are in this initialization process, which will come in handy in a little while. I also chose to complete initialization on the contained binding source first, then the grid, which makes sense: to get the grid’s data source initialized before the grid tries to complete its data-binding process against the binding source.

To test everything you have so far, do the following:

To understand how to fix this, you have to think about what controls and components are on the form and how they relate to one another.

When you add controls to a form, you are just adding instances of the controls that are members of the class to the Controls collection of the base class. So the FilteredGrid control that is added to the form is just one control on the form from the form’s perspective. Because FilteredGrid derives from UserControl, which derives from Control indirectly, it too has its own Controls collection, and this is the collection into which the grid and binding source inside the user control go. When you hooked up all the data binding in the form through the designer, what you effectively end up with is what is depicted in Figure 8.8 (minus the controls not directly involved in data binding yet).

FIGURE 8.8: Bound Controls in the Hosting Form and User Control

The customersBindingSource instance in the form is hooked up to the customersDataSet as its data source, with its DataMember set to the Customers table within that source. The filteredGrid1 instance has its DataSource set to the customersBindingSource, which just implicitly hooks the user control’s contained m_BindingSource instance up to that same binding source. The m_Grid instance inside the user control has its DataSource set to the m_BindingSource instance in the user control. When the data set gets filled out in the form’s Load event handler, the data shows up automatically in the grid through the handy work of the binding sources.

The problem with the data navigator is that it is hooked directly to the customersBindingSource in the form, and there is no automatic way for it to cascade the changes in the position for that binding source down into the one in the user control (m_BindingSource). This is because each binding source has its own currency manager under the covers, and they aren’t hooked up in a way that lets the binding sources know they are supposed to stay synchronized. To fix this, you need to do a little more work when you hook up the data source in the user control.

Chapter 7 briefly covered the ICurrencyManagerProvider interface, which is implemented by objects that host their own currency manager, as is the case with a BindingSource component. To be notified when the currency manager’s position in the form’s binding source changes within the user control’s binding source, you need to use the ICurrencyManagerProvider interface to detect when something will maintain its own currency manager, and you need to subscribe to that currency manager’s CurrentItemChanged event to keep things synchronized yourself. Listing 8.3 shows the modifications required to the set block of the DataSource property on the FilteredGrid control, as well as the event handler method that gets called.

As shown in Listing 8.3, each time a new data source is assigned, you have to check to see if it implements the ICurrencyManagerProvider interface. If so, you subscribe to the CurrentItemChanged event on the CurrencyManager exposed through the interface property. You also need to hold on to a reference to the currency manager, so you can unsubscribe from that event before releasing the reference to the data source when a new data source is assigned. The event handler updates the position of the binding source inside the user control to match the position of the currency manager that is set as the data source. Now if you ran the sample application, when you change the position with the data navigator, the cursor in the grid will be updated as well.

The next requirement we will tackle is to be able to dynamically populate the m_FieldCombo control in the FilteredGrid control with the columns or properties of the data items in the bound data source. When you create custom controls that support data binding like this, you should make as few assumptions as possible about the actual data types being bound to your control. For example, one way to support this functionality would be to say that your control can only be bound to DataTable objects (in which case you wouldn’t even need a DataMember property), and therefore you could just cast the DataSource to a DataTable, access its Columns collection, and obtain the column names from each of the DataColumn objects in that collection.

The problem with that approach is that you have just prevented anyone from using your control with a collection of custom business objects, which is a use case that you should support in the same way that the data-bound Framework controls do. Because the data-bound portion of your user control is a grid bound to a binding source, you can let the binding source worry about all the details of handling various kinds of data collections, which it does quite nicely. However, you need to be able to reach into whatever collection is bound to the binding source and determine what the names of the columns or properties are on each of the data items in the collection, and you need to do it in a way that makes no assumptions about the object type. Whether the data source is a data set, data table, or custom collection of business objects, your code needs to handle it properly, and preferably without writing a bunch of conditional tests to check for specific types.

Luckily, the Framework has some built-in support for doing exactly this through property descriptors (the PropertyDescriptor class—see Chapter 7 for a discussion of property descriptors). By using the GetProperties static method on the TypeDescriptor class, you can get back a PropertyDescriptorCollection instance containing all the property descriptors for all of an object’s properties, whether that object is a row in a table or an instance of a Foo business object.

The next requirement to tackle is not directly related to data binding, but is a common requirement for data input applications: the capability to autocomplete user input as they type it within input controls such as a TextBox or ComboBox control. This is a new capability provided in .NET 2.0, so let’s use it to enhance the filtered grid functionality.

The first step in the helper method is to verify that it is being called while initializing or while the collection of data or the filter field combo box is empty. If any of those are true, then the method simply returns because there isn’t enough information available to build the autocomplete string collection. If there is data to work with, it first clears the current collection of strings, which again is accessible through the AutoCompleteCustomSource property on the text box.

Next, an instance of an AutoCompleteStringCollection is created to add your new filter values to. The method then enters a loop to step through each row in the data collection, and uses property descriptors and the Find method to locate the field or property on each item with the name of the field selected in the combo box. It then extracts the current value of that field with the GetValue method on the property descriptor and adds it to the collection of filter strings. Once the loop is complete, the code replaces the AutoCompleteCustomSource string collection with the one just created.

As with the BindFilterFields method, you need to call this helper method from an appropriate place, which includes two places.

If you run the sample at this point, the grid and filter field combo box should populate with data and column names respectively, and if you select a particular field in the combo box and start typing a value, you should see autocomplete kick in, as shown in Figure 8.6.

You are almost done with the filtering capabilities. The last thing you need to do is to make the selected filter take effect on the presented rows in the grid. To do this, add a handler for the Filter button named OnFilterClicked, with the code shown in Listing 8.6.

To do the actual filtering, use the inherent capability of the BindingSource itself to do the dirty work. All you need to do in your Filter button Click event handler is to tell it what to filter on, which needs to be a valid Filter expression. The filter expressions supported by the BindingSource are simpler than those used by the DataColumn.Expression property, in that you don’t have different delimiters for different data types. You just delimit the value of the filter property or field with single quotes, and it will work fine for numeric and date types as well. However, the underlying data source does need to support filtering, meaning it needs to implement the IBindingListView interface (discussed in Chapters 7 and 9).

The first thing the filter method does is to check to make sure there is data to work with; if not, it returns. The next thing is that if a blank filter expression is entered, it is treated as clearing the filter expression, so the code checks to see if the text box is empty and if so, sets the binding source’s Filter property to null. Notice the call to string.IsNullOrEmpty. This is a new method added to the string class in .NET 2.0, and it saves having to declare a long conditional statement that checks both for an empty string and for a null string, a very common requirement in code dealing with strings. In this case it is somewhat unnecessary, since the TextBox control always returns an empty string when blank (but I decided to include it here so you’d be aware of it).

After that, the code grabs the field name from the combo box and the filter string from the text box, and uses them to construct a filter expression with the string.Format method and set that as the Filter property on the binding source. With this in place, you should be able to type in filter values into the text box at runtime, see autocomplete kick in to help you select appropriate values, and then tailor the grid to matching values when you click the Filter button.

I want to add one more feature to this control before we declare it done. Because programmers using your FilteredGrid control won’t have direct access to the DataGridView that it contains, there is no opportunity for them to declaratively set the column names, widths, and such through the designer—this just automatically generates the columns based on the data. One of the most common desires when this is done is to have the column widths also set automatically to display the contained content without wrapping. As discussed in Chapter 6, the DataGridViewColumn class has an AutoSizeMode property that you can set to AllCells (or a number of other settings) to achieve this presentation effect. So what you need to add to your FilteredGrid is some code to set that property on the automatically generated columns of data. You probably also want to allow programmers using your control to turn this feature off as well.

To set that property on the columns, the columns naturally have to exist, which doesn’t happen until after data binding is complete. Luckily, the DataGridView control raises an event called DataBindingComplete when that occurs, giving you the perfect place to do this kind of post-data-binding processing.

The code for the DataBindingComplete event handler loops through each of the columns in the grid, setting the AutoSizeCriteria property to the appropriate enumerated value.

With that, you have a fairly complete functioning example of a custom data-bound control, created as a user control, containing other data-bound controls, and managed through a contained binding source. Approaching things this way gives you a clean way to encapsulate functionality in a single control that can be reused in many places, and lets you harness the powers of the built-in Framework data-bound controls to their full extent without having to know anything about them beyond their public properties, methods, and events.

You could certainly continue to enhance the capabilities of this control by surfacing additional properties on your control that you then delegate in appropriate ways to the contained controls and components. You might want to expose the contents of the filtered list so that other programmers can grab those filtered data items and do something with them as their own list. Obviously, caching all the autocomplete values of every row for the selected filter field in the grid in memory can be a scalability concern if you try to use this control for very large data sets. To address that, you would need to come up with a more robust way of populating the autocomplete list—or do away with that requirement. By doing things like this, you add capabilities to your control with minimal code, but limit what is exposed to the user of your control, which is a good approach to component-oriented development from an encapsulation point of view.

If you really want to expose the full API or a significant subset of it from the grid to the users of your control, you may want to expose just a property on your control that gives them direct access to a reference to the grid. However, that still won’t give them access to the designer capabilities of working with a DataGridView control, so if you need to support that as well, you might need to step back to deriving a class from the DataGridView control. At that point you have to tackle the full complexities of integrating custom code into the processing model of the Framework control, which again requires pretty intimate knowledge of all of the control’s internal details. An alternate approach would be to create a custom designer class for your control that provides similar capabilities to that of the DataGridView, as discussed in the sidebar “Supporting Rich Design-Time Declarative Programming.”

The full FilteredGrid example and a sample hosting Windows Forms application are available in the CustomControls project download code for this book.

So far I have presented examples of deriving from a built-in Framework control or developing a user control that contains other controls and exposing a data-binding interface on that user control. However, sometimes you may need to build custom controls that aren’t simple containment scenarios for existing Framework controls, and you may want to support data binding on these controls as well. If you can at least handle containing a binding source component as a child component of your control, you can let it do most of the data-binding dirty work, as you saw in the last example with the FilteredGrid. That control inherently supports all the myriad forms of data collections that the Framework controls do, simply because it is using a binding source to sort the data from whatever is provided as a data source and data member.

In case you need to be more directly in the loop for rendering your control and accessing the data that is bound to it, you may have to eschew the support of the binding source and drop back to dealing with different forms of data collections yourself. If you do this, one approach would be to handle all the different interface types described in Chapter 7 directly, figuring out whether you have a list, a list of lists, a list of lists of lists, and so on, and figuring out type information and sorting and filtering capabilities on your own. There is still some other support in the Windows Forms classes that can save you some of this grunt work without using a binding source, as you will see in the next example. So to demonstrate getting a little “closer to the metal” and how to implement a data-bound control that doesn’t rely on any Framework controls for its data binding, let’s jump right into another example.

The scenario for this sample control is that you need to build a data-bound charting control that will render bar chart data for comparative purposes to help decision makers...well, make decisions based on that data. You can call this decision support, knowledge management, business intelligence, or whatever your favorite buzzword is for this kind of functionality. Obviously, to create a production-capable rich graphic control that executives would use to make billion dollar decisions is going to take a little more code than I have room or time for in this chapter. So I am going to limit the functionality and presentation graphics to a fairly crude and simple set of bar charts that can be generated dynamically from data with an appropriate shape.

This example will support users who are going to provide sets of data to the control. The sets of data contain numeric data series representing categories that I want to compare on two axes. Each row of data represents some entity; within each row will be sets of numeric fields, which each represent some category of data supported by each entity that the row represents. By presenting each row as a series of graphical bars, decision makers can quickly scan complex numerical data looking for trends and indicators. For example, consider a set of data where each row represents a sales year, and then within that row are data fields containing the net sales amounts for each sales region in your organization. If you had that kind of scenario and wanted to let executives quickly review that data for comparison purposes between years and regions, you could present it as shown in Figure 8.9.

FIGURE 8.9: DataBoundBarChartControl in Action

As soon as you start designing for specialized data-binding scenarios like this, you step out of the realm of the generalized data binding that the Framework controls support. In this case, we have specified that the data that the control supports needs to have a particular shape. We could make this more explicit by perhaps defining a specific interface that the data collections have to support, say IDecisionSupportDataList, and then program against methods or properties exposed by that interface. This would model what the Framework controls do with respect to assuming that the data supports the IList interface. However, for many scenarios that may be overkill, and you will just want to support a particular shape of data based on assumptions of what you should find in data sources bound to the control, and then handle errors accordingly if those assumptions aren’t met. That is how we’ll approach things in this example. Defining a separate interface that describes a certain kind of data collection might make sense if you were going to define multiple controls that made the same assumptions about the shape of the data, but that would impose an additional nonstandard implementation burden on any data collections you want to use with your controls, which would limit its usability.

So let’s design a control that looks like Figure 8.9. It should provide the data that drives the presentation dynamically in a way that models the data-binding support in the Framework Windows Forms controls. Additionally, it should support both relational data sources, such as data sets, as well as custom business object collections. The data collections provided as a data source and data member are expected to have a single column or property that is the row identifier and will be used to label the row. They are also expected to have any number of additional columns or properties of numeric types that will be used to generate the bars with their values and property names.

Once the BarChartControl control has been coded and debugged (by making it public and allowing a containing form to populate the data directly), you can create the data-bound containing control that creates and populates an instance of the BarChartControl for each row of analysis data. In this example I created this as a user control to be able to automatically provide a scroll bar to use when more rows of data (BarChartControl instances) are added that can be presented within the control’s size.

Because the control is supposed to support data binding in a fashion similar to other data-bound controls, it will need DataSource and DataMember properties. The control presentation’s coupling to part of the individual data items in the bound collection (the need to use one of the fields in each data item as a label for the row) requires that the control also needs a property that lets users of the control specify what the field or property name is that contains the row identifier. This is similar in concept to the function of the DisplayMember and ValueMember properties on a ComboBox or ListBox control, and I will call the property RowIdentifierMember.

Presenting data is really only one-way data binding—from the data source to the screen. Most Windows Forms data-bound controls support some sort of two-way data binding—letting the user modify values in the control, which directly modifies the values in the underlying data collection. There are a number of different levels to which you can take this. If you recall from Chapter 7, the IList interface contains a Boolean property named IsReadOnly, which returns true if the list isn’t intended to be modified by the consumer of the list. The meaning of IsReadOnly can be interpreted in a number of ways, so the IBindingList interface refines this by adding AllowEdit, AllowNew, and AllowRemove properties to explicitly indicate whether the collection allows the editing of individual items in the collection, the addition of items, or the removal of items, respectively.

If you want to design a control to allow editing of the presented values, you need to use these interfaces to decide whether you should be trying to edit the collection of data represented by your data source and what kinds of edits you should allow.

As a simple example, let’s add some modifications to the BarChartControl and DataBoundBarChartControl to let users edit the presented values in a crude fashion. Specifically, end users can left-click on a bar to increase its value by 10 percent, or right-click on a bar to decrease its value by 10 percent. The control should only allow this interaction when the data is editable, meaning that the list is not read-only, and that if the collection supports the IBindingList interface, it specifically says that it allows editing of the contained values.

To support this functionality, the first step is to modify the BarChartControl to support the form of editing described earlier. This involves adding a property to indicate whether the bar should be editable based on the data it was created from, and a mouse-click handler to detect and react to mouse clicks if the control is in editable mode. There also needs to be a way to propagate the changed values back out to the containing control, which will be responsible for pushing them into the underlying data collection.

The modifications to the BarChartControl are shown in Listing 8.11.

The way that the control supports editing is to add a handler for mouse-click events and to modify the values of the chart pairs contained in the control directly. However, to support two-way data binding, those changes have to be propagated outside of the control to the containing control so that the data-bound container control can update the data source from whence the values came. To support that, the control needs to raise an event that indicates that the bar was changed and which value within it changed. To support raising that event, the code in Listing 8.11 starts with a delegate definition called BarChartChangedEventHandler. This delegate’s parameters include a reference to the object (the control) that is firing the event, as well as the index of the data item that was modified. A corresponding event is declared on the BarChartControl class called DataValueChanged; it is this event that will be subscribed and handled by the containing data-bound charting control.

The data presented in the control can change in one of two ways: an end user clicking on a bar in the control, or programmatically outside the control through the Data property reference to the collection of ChartPairs. For the changes that are made directly to the data in the mouse-click event handler, you could raise the DataValueChanged event handler yourself. But how are you supposed to know when a data value has changed inside of the data collection of chart pairs if it is done outside of the control?

This is the reason that I implemented the collection using the BindingList<T> generic type. That type can automatically provide support for ListChanged events, even for modifications to the contained data values through bound controls. So by simply containing your data values inside a BindingList<T> type, and then handling the ListChanged event from that type, you can be notified any time a contained value changes, whether you did it yourself or whether it is done externally through the Data property reference. This lets you centralize your handling for changing values to one place, which is simply to tell the control to update itself (through the UpdateCoordinates method), and to fire the DataValueChanged event if the change type is an edited value and if there are any subscribers.

The AllowEdit property gets or sets the corresponding property on the contained BindingList<T> collection, which is checked by the mouse-click event handler to decide whether to process the mouse click as an edit. The mouse-click event handler does some simple hit detection on the rectangles calculated and stored by the UpdateCoordinates method, and if it sees that a mouse click is inside one of the bars, it increases or decreases the value by 10 percent, depending on which mouse button was clicked.

Now you need to add the corresponding support to the DataBoundBarChartControl control to update the corresponding data source if appropriate and control the editability of the individual bar chart controls. The modified portions of the control are shown in bold in Listing 8.12.

To keep track of enough information to change the bound data list when a change occurs inside an individual instance of a bar chart control, several new members had to be added:

When the data source is updated and UpdateDataBinding is called, you hold on to a reference to the bound list and set the flag that indicates whether the source is updated based on either the IList.IsReadOnly flag or the IBindingList.AllowEdit property, depending on whether the list’s data source implements IBindingList.

When each bar chart control is added to your Controls list, the containing control subscribes to its DataValueChanged event and sets its editability based on that of the list. Finally, the handler for the DataValueChanged event on any of the contained bar chart controls uses the sender object reference to the control, along with the changed bar index, to reach back into that control, extract the changed value, find the corresponding value in the bound data list based on the index stored in the Hashtable for that object, and set its value depending on the actual type of the value in the list.

With those changes, you now have a data-bound custom control that supports presenting and editing data from a bound data source. Obviously there are a lot of things that you would want to add to a production control, such as a little better look-and-feel, more customizability, and better designer support as discussed earlier. If you expected other controls in a form to be bound to the same set of data, you would want to monitor other forms of ListChanged events on the data (based on the ListChangedType event argument property) and possibly subscribe to the currency manager’s CurrentItemChanged event, as was done in the filtered grid example, to monitor context changes to the data from other bound controls.