>>>Hi,
>>>I have the following Style defined for TreeViewItem:

<Style TargetType="TreeViewItem" x:Key="StdTreeViewItemStyle">
>>>       <Setter Property="Template">
>>>            <Setter.Value>
>>>                <!--  Standard TreeViewItem ControlTemplate pasted here -->
>>>           </Setter.Value>
>>>      </Setter>
>>>        <Setter Property="IsExpanded" Value="{Binding Path=IsExpanded, Mode=TwoWay}" />
>>>        <Setter Property="IsSelected" Value="{Binding Path=IsSelected, Mode=TwoWay}" />
>>>        <Style.Triggers>
>>>            <Trigger Property="IsSelected" Value="True">
>>>                <Setter Property="FontWeight" Value="Bold" />
>>>                <Setter Property="Foreground" Value="Red" />
>>>            </Trigger>
>>>        </Style.Triggers>
>>>    </Style>

Without the Template setter the IsExpanded and IsSelected bindings work fine. With the ControlTemplate in place they no longer work (before I've made any tweaks to the ControlTemplate). FWIW the Trigger *does* work.
>>>
>>>UPDATE: FWIW, the TreeView also uses a DataTemplate. This works without the ControlTemplate but with it, although the TemplateSelector is called and returns the relevant DataTemplate, the default template is actually used.......
>>>
>>>Any ideas what goes wrong here?
>>>TIA,
>>>Viv
>>
>>I assume the control template you are using actually handles "IsSelected" and "IsExpanded" in the Triggers? (I know, way too obvious, but had to ask.)
>
>For testing this it's exactly the same as the standard TreeViewItem template - so yes.
>
>>
>>One thing I see that is different from the way I write these. I always put the template last and the setters first, you have it template first and the setters last. Does it work if you switch it around? For some reason I think the setters have to exist before the template is defined. No clue why I think that.
>
>I had tried the other way around (no change). But I thought *my* way should be right since I wanted to override the IsSelected trigger and I thought the rule was 'last one wins' ?
>
>Oh, just discovered I can't put the ControlTemplate Property after the Trigger section anyway - compiler won't accept it. I can make the ControlTemplate the last property setter - but, as before, no change in behaviour.
>
>FWIW I also split this out into two styles, the first with just the ControlTemplate setter and the second 'BasedOn' this. This would actually be a better pattern for my needs - but the results were the same anyway.......
>
>Still groping for a solution on this.....
>Best,
>Viv

My last response was way too rushed and not well though out, so I stuffed this into a test project so I could see what was up. And try and remember my tree view stuff...

>>UPDATE: FWIW, the TreeView also uses a DataTemplate. This works without the ControlTemplate but with it, although the TemplateSelector is called and returns the relevant DataTemplate, the default template is actually used.......

DataTemplate or HierarchicalDataTemplate?

The template for a TreeViewIem is a bit weird. In my app what I see when I snoop it is that the HierarchicalDataTemplate/DataTemplate is hosted by the content presenter in the TreeViewItem. It doesn't actually replace the item template, both the data and item templates exist and are used. In fact it would break my app if they didn't.

Could that be part of what's causing the problem here?

I assume the bindings "{Binding Path=IsSelected, Mode=TwoWay}" etc. is to a property of the data? (I'll have to mock up some data that has that in it in order to test it.)

Edit: Not sure if this helps any but I thought I'd link it anyway. http://compilewith.net/2008/07/wpf-selecting-treeviewitems-in-code.html