During the last weeks I have not written any blog entries. Why? Together with Karin I have been working on our new book "WPF and XAML" that will come out in December (check out the book at Amazon). I never thought that writing 550 pages could be so hard. However, we finished the alpha-version of our manuscript yesterday. Therefore I have time to write some blogs again. Today about XmlDataProvider.
If you want to access XML data in data binding expressions, MSDN tells you that you have to use the XmlDataProvider-class. This class is - just like ObjectDataProvider - a DataSourceProvider:
XmlDataProvider...
- ...can access XML data that is embedded into a XAML file
- ...can load XML data using a URI (e.g. reading an existing XML file from disk)
- ...offers a Document property which you can assign your own instance of XmlDocument. You can generate or load the XmlDocument in any way you want.
- ...can load inline XML data or XML data from a file in a separate worker thread (UI is not blocked while loading the XML data)
Here is a short sample that shows how to use XmlDataProvider. It uses inline XML data that is embedded into the XAML file. The sample also shows how to create a binding expression that references the XmlDataProvider-object.
What's happening inside? XmlDataProvider loads (asynchronously or synchronously, depending on the setting in the IsAsynchronous property) the XML data into a XmlDocument-object. That leads us to the question that Karin and I was asking ourselves: Why using XmlDataProvider if we build the XmlDocument-object in code? Do we have to use XmlDataProvider and assign our own XmlDocument instance to the Document-property?
The answer is no! In such cases you can directly embed the XmlDocument object and forget about XmlDataProvider. The important thing is that you do not loose the ability to create data binding expressions using XPath=... Check out the following code sample. It works fine! Here is the XAML code:
Here is the code behind file in C#:
