There are a lot of lines of code here, but they fit into some neat categories that will help you understand what they do.
When programming XML, you have to learn to "think" XML first. The most fundamental organization of XML is a hierarchy. So, rather than writing the XML line-by-line as you might expect in a sequential file, the most direct way to write an XML file is to create it node-by-node and then write it. There are other techniques and you might want to experiment. You might find one that fits your way of thinking about it better.
In this program, the first statements create the XML declaration. This identifies the file as an XML file and is strictly required. Then a root node is created and populated with all of the content: child nodes and any XML attributes. (This program includes just one XML attribute, incByThousand, to the numShares element.) Finally the root node is appended to the XML document and the whole thing is written to a file. No path information is provided so this file is written to the same folder that the executable is in. I used the same names for the XML elements and attributes as I used for VB program variables just to make things easier to code. This isn't required.
In this program, reading the XML document back again requires you to change your thinking back to a sequential mode. Although Microsoft's System.Xml namespace gives you the tools to zero in on exactly what you need, in this case it's easiest to simply read through the XML in sequence and assign the data back into variables. I do this in the Load event for the form. A Do While loop moves through the XML document from front to back and a Select Case block simply extracts the values that the program needs.
One interesting sidenote that contributes to confusion is that the Value property of an XML node can be used some of the time and some of the time it can't. The Tool-Tip unhelpfully tells us that Value "Gets the text value of the current node."
Not exactly right.
For example, this statement compiles, but creates an exception when the program runs:
Child.Value = companyName.Text
This statement works fine when the node type is an attribute but always assigns a null reference when the node type is an element.
varName = Input.Value
This MSDN page tells you when it works and when it doesn't. Although their documentation could be a lot more clear about why things work this way, you can't really blame Microsoft for the problem. The cause is the very exact way that XML works. For example, a node in XML might look like this:
<node>FirstData<emptysubnode/>SecondData</node>
What's the "value" of the element node? Is it "FirstData"? Or "FirstDataSecondData"? Microsoft's very complete System.Xml namespace has methods to deal with every possibility, but some of them don't make sense until you have more experience with XML.
The final result is a fairly simple way to read and write an XML file that you can adapt to work with most projects. The complete application with both the create and read code for the XML configuration file can be downloaded here.
