So we've proved now that not only do changes to the XmlDataDocument object affect the DataSet, but also that the opposite is true.
It's worth looking at how we built up the view, as it's another example of how we can use recursion to walk through the nodes that make up the document. In fact, because we can see the results, it may make the process clearer if it's still a little foggy.
Again, when DoUpdateView is called, we pass in the node that represents the starting position. At first, this will be the start tag for the top-level element.
' DoUpdateView - go through adding nodes...
Protected Sub DoUpdateView(ByVal node As XmlNode, ByVal level As Integer)
' Go through the nodes...
Do While Not node Is Nothing
For each one, we want to make up a string and add it to the ListBox. Depending on the level, we want to indent the string so on the first level there is no indentation, on the second level there's some indentation, on the third there's a little more, and so on. The level that we're working at will be passed in through the level parameter.
' Create a new string...
Dim nodeString As String = ""
Dim n As Integer
For n = 0 To level - 1
nodeString &= " "
Next
Once we've added an indent to a string, we can render the type that the node is. We then tack on either the name of the element or, if we have one, the current value.
nodeString &= node.NodeType.ToString() & ":"
If node.Value = "" Then
nodeString &= node.Name
Else
nodeString &= node.Value
End If
Then we can add the string to the ListBox:
' Add it...
lstNodes.Items.Add(nodeString)
As before, as soon as we've done one element we need to call into the function again to do the children. We pass an incremented version of level into the function, and this lets us adjust the indentation.
' Do the children...
DoUpdateView(node.FirstChild, level + 1)
After we've walked through the children, we can move onto the next sibling.
' Next...
node = node.NextSibling
Loop
End Sub
OK, so that's how the view is put together, and you can see that it follows the structure of the document as we see it displayed in Internet Explorer. (Using this method the end tags aren't displayed, but this is no big deal!) But, have we really proven that the objects are being synchronized, or are we showing that some funny business is going on?
If we look at the DataSet property, we can see that it's at that point that we set the Document property on our XmlDocumentView object.
' DataSet property...
Public Property DataSet() As DataSet
Get
Return _dataset
End Get
Set(ByVal Value As DataSet)
' Save it...
_dataset = Value
' Bind...
datagridOrders.DataSource = _dataset
datagridOrders.DataMember = _dataset.Tables(0).TableName
' Create the document...
_document = New XmlDataDocument(_dataset)
' Update the view...
_documentView.Document = _document
End Set
End Property
This is the only time this happens, and the only time that the DataSet property is set is after we've pressed the Connect or Load buttons.
When the current cell is changed on the DataGrid, we run this code:
Private Sub datagridOrders_CurrentCellChanged(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles datagridOrders.CurrentCellChanged
_documentView.UpdateView()
End Sub
We know that this code just goes through the document that's stored in the DataSet public member on XmlDocumentView. As this isn't changing, the only reasonable conclusion that we can come to is that the DataSet is indeed updating the XmlDataDocument.