Now, as promised, we get back to differences in the DataGrid editing logic that take place when a new data row is added. One should be aware that not all types of data sources support adding new rows, only those which implement the IBindingList interface actually do. Therefore, we will assume that the DataGrid is bound to a DataSet or to a DataTable for our further explanation. The IBindingList interface is actually implemented by the DataView and the DataViewManager classes, so a DataView instance is implicitly created for each DataGrid’s CurrencyManager in case of a DataTable or a DataSet bound to it.

Now that the prerequisites have been discussed we can move on. When the user clicks on the new row addition area (the one marked with a small “*” icon), a new data row is created in the corresponding DataView but not yet in the DataTable the view has been created for. If we examine the RowState property for the corresponding DataRow, we find out that the data row is marked as Detached, which means the row does not belong to any DataTable yet.

The usual editing sequence is then carried out as if the new row was any other row. The next difference is introduced at the point when the new row values have been either committed or the editing have been rolled back. Upon the successful commit, the new row is actually added to the data source and its RowState is changed to “Added”. If the editing has been rolled back, the new row is completely removed from the DataView – this prevents the user from a multitude of blank rows that are added every time she clicks on the asterisk-marked area.

TIP: For DataTables and DataSets, the underlying row that has been added is marked with the Added value of its RowState property. This can be used later to determine which rows has been added by the user and should be somehow processed.

Another interesting point I would like to discuss is how editing works for a sorted DataGrid. As you might have noticed, if a cell being edited belongs to a column the grid is currently sorted by, the row “jumps” to its correct place in the sort order when the user has entered new cell value and moves off the cell. While we cannot prevent this jumping, we can determine the old index of the row before it jumps. To do that, we will subscribe to the ListChanged event of the DataView.

CurrencyManager cm = (CurrencyManager)this.BindingContext[dataGrid.DataSource, dataGrid.DataMember];

DataView theView = (DataView)cm.List;
theView.ListChanged += ListChangedEventHandler(ListChangedHandler);

Now, within the handler, we will check the ListChangedType property to react only on ItemMoved notifications we are interested in. When such a notification arrives, we can analyze the values of the OldIndex and the NewIndex properties to determine the old row index and the new row index respectively.

private void ListChangedHandler( object sender, ListChangedEventArgs e) {
    if (e.ListChangedType == ListChangedType.ItemMoved) {
        int oldIndex = e.OldIndex;
        int oldIndex = e.NewIndex;
    }
}

And finally, a simple trick to force the DataGrid to complete current editing. This trick will be useful any time you want to complete editing programmatically – for example, when the user clicks the OK button in a dialog box. You will need to perform two actions:
Tell the DataGrid to exit editing mode and save the data.

1. Tell the corresponding CurrencyManager to push the data back to the data source.

Calling the DataGrid’s EndEdit method carries out the first step. This method requires a reference to the DataGridColumnStyle instance for the column being edited, so you will have to create grid column styles manually – you won’t be able to access the grid column styles created by default.

The corresponding DataRow fields will have been updated by the time the DataGrid quits the editing mode, but row status won’t be changed – and if the row have just been created, it won’t be attached to any table.

The CurrencyManager’s EndCurrentEdit method should be called to complete the second step. After this call the row will have correct status and will be added to the DataTable if necessary.

Conclusion

In the first part of the article we have taken a closer look at the inner life of the data grid control and have taken a walk through the intricacies of its navigation and data editing logic. We have also written several pieces of code to add small but convenient features to the DataGrid control. At this point you might wish to start implementing your extended version of the DataGrid, and I absolutely encourage you to do so as well as I would suggest including these small features for a start.