Navigation

Search

Categories

On this page

Databinding to a XmlDataProvider in WPF
How to remove the horizontal scrollbar from a ListView

Archive

Blogroll

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 120
This Year: 1
This Month: 0
This Week: 0
Comments: 40

Sign In
Pick a theme:

# Tuesday, October 06, 2009
Tuesday, October 06, 2009 9:46:36 AM (Mountain Daylight Time, UTC-06:00) ( All things Microsoft | Code )
I've resolved to start making the shift to WPF. It's about time. The technology has only been around for a good 3+ years. So far, I'm very excited by what I see. An invaluable reference has been Programming WPF 2nd edition by Chris Sells. Specifically the appendices. The explination of Xaml, and the Xaml Extensions removes the veil of confusion from all of the arcane looking symbols going on in the Xaml code. Thanks for the awesome book Chris! I was going through an article published in MSDN Magazine, Data Binding in WPF by John Papa. I encountered a very frustrating bug and I felt the need to let the next developer know about the solution I uncovered. (The next developer is sometimes me. I do very much love finding my own posts months or years down the road that help me out). Maybe this will help you out.

So, I'm building my Xaml out, and I have a perfectly good XmlDataProvider in my Resources.
<XmlDataProvider x:Key="MoreColors" XPath="/colors">
<x:XData>
<colors>
<color name="pink"/>
<color name="white"/>
<color name="black"/>
<color name="cyan"/>
<color name="gray"/>
<color name="magenta"/>
</colors>
</x:XData>
</XmlDataProvider>

I Created the Binding to my Listbox as such.


This whole thing is working in the Designer (Visual Studio 2008), but is displaying nothing at runtime. I whisk away to the MSDN Documentation for XmlDataProvider and find this clever little note.

The root node of the XML data has an xmlns attribute that sets the XML namespace to an empty string. This is a requirement for applying XPath queries to a data island that is inline within the XAML page. In this inline case, the XAML, and thus the data island, inherits the System.Windows namespace. Because of this, you need to set the namespace blank to keep XPath queries from being qualified by the System.Windows namespace, which would misdirect the queries.
Is it possible that this is the explination to the Debug output I'm seeing in Visual Studio at runtime?

System.Windows.Data Error: 47 : XmlDataProvider has inline XML that does not explicitly set its XmlNamespace (xmlns="").

I add the missing xmlns="" to the root xml element (as shown below), and things begin to work at runtime.

<XmlDataProvider x:Key="MoreColors" XPath="/colors">
<x:XData>
<colors xmlns="">
<color name="pink"/>
<color name="white"/>

In searching for the answer to this solution, I also came across this post Why WPF databinding is an awful technology. I hope this is not shared feeling of frustration many of us receive by wasted hours of our day with the Moteur de recherche du jour (search engine of the day). It's a really useful tool if you can convince it to give you the right answer, and people have posted about the particular phrase you're looking for.

Good luck reader, with your journey to WPF enlightenment. It has been worth my time.

Comments [0] | | # 
# Thursday, October 01, 2009
Thursday, October 01, 2009 10:05:19 AM (Mountain Daylight Time, UTC-06:00) ( All things Microsoft | Code )

When you have a ListView control in Windows Forms, and you don't want the horizontal scroll bar to show up, you need to set the size of the columns to be the same 'Width' as the ListView.
What exactly is the 'Width' you should use here? Yes careful reader, I've been quoting Width because we need to take a closer look at what's going on.
Lets look at a dead simple example to clearly illustrate why this is a concern.

When I create a new Windows Forms application in Visual Studio, I get a standard sized form. Dragging a ListView control from the toolbox will create a control with the dimensions defined as

private void InitializeComponent()
{
   ...
   this.listView1.Size = new System.Drawing.Size(121, 97);
   ...
}
I added the following code to constructor of the Form after the InitializeComponent() call;
void Form1()
{
   InitializeComponent();
   
   listView1.Columns.Add("Name");
   for (int i = 0; i < 20; i++)
   {
      listView1.Items.Add(new string((char)(i + 33), 10));
   }
   // Naive width
   listView1.Columns[0].Width = listView1.Width;
}

What we end up with looks like the image below.

This is definately not what we wanted. Even though none of my data is forcing my scroll behavior, my column definition definitely is. I could change this to use the ClientSize of the Control, I know that's smaller. The documentation on MSDN for Control.ClientSize makes these remarks about the property.

"The client area of a control is the bounds of the control, minus the nonclient elements such as scroll bars, borders, title bars, and menus..."
This will work right? I'll just make a quick change to the code, recompile and... drat. No love.
    // Setting the width on the Column
   //listView1.Columns[0].Width = listView1.Width;
   //listView1.Columns[0].Width = listView1.ClientSize.Width;

}

What is going on here?!
As it turns out, the calculation for ClientSize in the constructor is completely correct. The control hasn't been drawn yet, and it has no knowledge of whether it will need to use a vertical scrollbar to display the data. That's just fine control. I know how to fix you. I know how wide a scroll bar is, and I can figure that out on my own... Just watch me.

   // Setting the width on the Column
   //listView1.Columns[0].Width = listView1.Width;
   //listView1.Columns[0].Width = listView1.ClientSize.Width;
   listView1.Columns[0].Width = listView1.ClientSize.Width - SystemInformation.VerticalScrollBarWidth;
}

Ha! Take that ListView. Now my column displays perfectly, and I have no Horizontal ScrollBar to contend with. Just to prove it to you, I'm going to check how wide it should be after the form shows up, to make sure I'm right...

      //listView1.Columns[0].Width = listView1.Width;
   //listView1.Columns[0].Width = listView1.ClientSize.Width;
   Debug.Print("ListView is {0} px wide and has a client width of {1} px", listView1.Width, listView1.ClientSize.Width);
   Debug.Print("VerticalScrollBarWidth: {0}", SystemInformation.VerticalScrollBarWidth);
   Debug.Print("Calculated width: {0}", listView1.ClientSize.Width - SystemInformation.VerticalScrollBarWidth);
   listView1.Columns[0].Width = listView1.ClientSize.Width - SystemInformation.VerticalScrollBarWidth;
   this.Load += new EventHandler(Form1_Load);
}
void Form1_Load(object sender, EventArgs e)
{
   Debug.Print("Loaded width: {0}", listView1.ClientSize.Width - SystemInformation.VerticalScrollBarWidth);
}
Debug Output:
ListView is 121 px wide and has a client width of 117 px
VerticalScrollBarWidth: 17
Calculated width: 100
Loaded width: 100

Uh-oh. I have a bad feeling. It seems like the Width of the ClientSize after the control has been painted is different than before it was painted. Could it be that when the VerticalScrollBar is painted, the control does in fact know how much room it has left to use to paint on the screen?! Isn't that in fact, exactly what the Remarks of the ClientSize property told me? Do the numbers above not in fact make perfect sense!? Is 117 - 17 = 100?! Yes... sigh. Perhaps I should have meditated on the implications that the remarks on MSDN were accurate from the begging.

"The client area of a control is the bounds of the control, minus the nonclient elements such as scroll bars, borders, title bars, and menus..."

As it turns out, the correct time to set the width of a ListView Column is AFTER you've determined that there will be scrollbars painted on the control.

Comments [0] | | #