I have a form that has a case where DataContext is set to some object in the constructor:
Code:
private mFoo as Bar
private mBarList as New List(of Bar)

Public sub New()
mBarList(mFoo)
mBarList(New Bar)

Me.DataContext = mFoo

End Sub
This is somewhat contrived. The constructor is actually given the list of Bar rather than it being constructed, but that doesn't matter for this example. The point is that there is a list of Bar, mFoo is in that list, but mFoo is also a private variable at form scope.

In the XAML, I have a datatrigger like so:

Code:
<DataTrigger Binding="{Binding Path=SomePropertyofFoo, Mode=OneWay}" Value="1">
    <Setter Property="Background" Value="green"></Setter>
</DataTrigger>
There are a couple other, similar data triggers, as what I am doing with this is changing the background color of some buttons based on a property of Foo.

This works up to a point. However, there are Back and Next buttons, which swap mFoo for a different Bar in the list, as one might expect. The user can iterate through all the Bar in the list, each one being put into mFoo in turn.

The swapping works, but that datatrigger does not. I can confirm that pressing any of the buttons does what it should, and uses the new mFoo (which it pretty much has to, since that part isn't using binding), but the color of the buttons remains the same. It certainly looks like the binding is sticking with not the contents of mFoo, but with whichever object in the mBarList set that it was originally bound to.

Basically, it's binding to the actual object, not to 'the object whose reference is held in the mFoo variable'. In other words, it stays bound to the same object even when the object in the variable changes.

I can live with this, but I'm wondering if that is, indeed, the case, and whether there is a simple fix for this. It would have to be simple, though, because there IS a simple fix that can solve this problem by getting rid of the datatriggers and changing the colors in code. So, what I'm really looking for as a solution is a way to deal with this and still use the XAML approach for this coloring.