This site uses cookies to deliver our services and to show you relevant ads and job listings.
By using our site, you acknowledge that you have read and understand our Cookie Policy, Privacy Policy, and our Terms of Service.
Your use of Stack Overflow’s Products and Services, including the Stack Overflow Network, is subject to these policies and terms.

Join us in building a kind, collaborative learning community via our updated
Code of Conduct.

12 Answers
12

The binding problem comes from the default style for ListBoxItem. By default when applying styles to elements WPF looks for the default styles and applies each property that is not specifically set in the custom style from the default style. Refer to this great blog post By Ian Griffiths for more details on this behavior.

Note that I have removed the ControlTemplate to make it compact (I have used StyleSnooper - to retrieve the style). You can see that there is a binding with a relative source set to ancestor with type ItemsControl. So in your case the ListBoxItems that are created when binding did not find their ItemsControl. Can you provide more info with what is the ItemsSource for your ListBox?

P.S.: One way to remove the errors is to create new setters for HorizontalContentAlignment and VerticalContentAlignment in your custom Style.

+1, even if just for the link to StyleSnooper :)
– Drew NoakesAug 27 '09 at 17:35

2

+1 for the pointer to Ian Griffith's post. That is hands-down, one of the best descriptions on how elements get styled ... that I've ever read.
– cplottsJul 29 '10 at 15:04

4

Also, having a setter for HorizontalContentAlignment in my custom Style, did NOT seem to make a difference for me (this is for a ComboBoxItem though).
– cplottsJul 29 '10 at 15:15

+1 for the whole answer, should be marked as the right answer, worked perfectly for me
– DavidDec 15 '10 at 14:15

1

I tried setting HorizontalContentAlignment, VerticalContentAlignment, HorizontalAlignment, and VerticalAlignment for my ListBoxItem style and it failed. I think it has to do with the interaction between the ListBoxItem and the ControlTemplate's scrollviewer.
– WilliamFeb 6 '13 at 19:01

True, but it also caused my item to not present itself properly. Make sure that if you do this, you have enough of the style specified that you don't need anything from the default (see @ligaz's answer above)
– Drew NoakesJul 14 '09 at 18:17

@JTango it helps; I did it for my CustromTreeViewItem object and I have no more exceptions like those described
– DrakeApr 16 '10 at 14:11

This solved an issue I had as well. In our controls we are completely re-styling them so we didn't want the default style used anyway. Didn't even know about this property of Style. Thank you!
– scobiApr 22 '11 at 16:43

This is a common problem with ListBoxItems and other ephemeral *Item containers. They are created asynchronously/on the fly, while the ItemsControl is loaded/rendered. You have to attach to ListBox.ItemContainerGenerator's StatusChanged event and wait for the Status to become ItemsGenerated before trying to access them.

Can you elaborate on this? I think this is my issue. I'm trying to bind IsSelected property to my ListBoxItem via styling, but because of this exception thrown group selections are not toggled as expected when ListBox.SelectionMode=Extended. How would I go about intercepting the communication between the IsSelected Item and have it wait for the StatusChanged event to finish firing?
– WilliamFeb 6 '13 at 19:04

I don't really have the time to investigate further at the moment, but I suspect it's related to the default style that JTango mentions in his answer - I'm not really customising my template to a huge degree.

I think there's more mileage to be had out of the other answers, but I thought I'd post this on the off chance it helps someone in the same boat.

After some experimenting I discovered that the error was only triggered when the number of items exceeded the visible height of my ListBox (e.g. when vertical scrollbars appear).
So I immediately thought about virtualization and tried this:

This solved the problem for me.
Although I would prefer to keep virtualization turned on I did not use any more time to dive into it.
My application is a bit on the complex side with mulitiple levels of grids, dock panels etc. and some asynch method calls.
I was not able to reproduce the problem in a simpler application.

This solves my problem too. I guess the bindings fire before the item is completly loaded. In my opinion, this is a bug, and as such I have filed it with MSDN (though I'm sure I'm not the first) and posted this as a workaround.
– WilliamFeb 6 '13 at 19:10

Another workaround/solution that worked for me was to suppress these errors (actually, it seems more appropriate to call them warnings) by setting the data binding source switch level as critical in constructor of the class or a top level window -

According to the Data Templating Overview on MSDN, DataTemplates should be used as the ItemTemplate to define how the data is presented, while a Style would be used as the ItemContainerStyle to style just the generated container, such as ListBoxItem.

However, it appears that you are trying to use the latter to do the job of the former. I can't recreate your situation without much more code, but I suspect that doing databinding in the container style could be throwing a wrench in the assumed visual/logical tree.

I also can't help but think that a custom layout of items based on the item's information calls for creating a custom Panel. It's probably better for the custom Panel to layout the items than for the items to lay themselves out with a Rube Goldberg assortment of IValueConverters.

If you want to completely replace the ListBoxItem template such that no selection is visible (perhaps you want the look of ItemsControl with the grouping/etc behaviour of ListBox) then you can use this style:

Simply creating a default style for the type "ComboBoxItem" doesn't work, because it it overwritten by the ComboBox's default "ItemContainerStyle". To really get rid of this, you need to change the default "ItemContainerStyle" for ComboBoxes, like this:

I started running into this problem, even though my ListBox had both a Style and an ItemContainerStyle set - and these named styles had already defined HorizontalContentAlignment. I was using CheckBox controls to turn on/off live filtering on my ListBox and this seemed to be causing the items to pull instead from the default style instead of my assigned styles. Most errors would occur the first time the live filtering kicked in, but thereafter it would continue to throw 2 errors on each change. I find it interesting that exactly 2 records in my collection were empty and thus had nothing to display in the item. So this seems to have contibuted. I plan to create default data to be displayed when a record is empty.

Carter's suggestion worked for me. Adding a separate "default" style with no key and a TargetType="ListBoxItem" that defined the HorizontalContentAlignment property solved the problem. I didn't even need to set the OverridesDefaultStyle property for it.