Custom TreeViewItem template not working correctly for type GridView

[tmr4]

I created a tree view similar to your "Pictures and Music Library tree view" example except I replaced the text block in the data template with a grid view with two text blocks. This caused two problems with nested nodes: (1) when a node is expanded the first column of grid view items in the child nodes aren't rendered until you mouse over them, and (2) the child nodes are rendered out of order after expanding a second time (i.e., expanding a parent node, collapsing it and expanding it again). Internally the child nodes are still in the correct order because if you change to a simple text block data template while debugging the child nodes will be rendered instantly in the correct order.

Here is my data template using a grid view in which child nodes are rendered out of order on expanding the parent node a second time:
<DataTemplate x:Key="TreeViewItemDataTemplate1">
<GridView>
<TextBlock Text="{Binding Content.Column1Item}"/>
<TextBlock Text="{Binding Content.Column2Item}"/>
</GridView>
</DataTemplate>

This doesn't happen when using this simple data template (Content displays the ToString of the class):
<DataTemplate x:Key="TreeViewItemDataTemplate">
<Grid>
<TextBlock Text="{Binding Content}"/>
</Grid>
</DataTemplate>
If fact switching the data template live in xaml during a debug session will switch the order of the child nodes to the correct order.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d5ba995b-8bf3-407c-7b87-015d22d813f1
• Version Independent ID: 52c553b6-e94d-2810-4123-8ee215b002bf
• Content: Tree view - UWP app developer
• Content Source: windows-apps-src/design/controls-and-patterns/tree-view.md
• GitHub Login: @jwmsft
• Microsoft Alias: jimwalk

[tmr4]

Also clearing the tree view root node (as in treeView.RootNodes.Clear()) doesn't work as one would expect, at least in the case of using a data template with GridView vs a simple TextBlock as noted above. Visually the tree view will be cleared, but new nodes will have the contents of the previous tree view, but in reverse order. When first adding a node to the cleared tree view it seems to recreate the old treeview node structure internally and then as nodes are added their content will be that of the previous tree. I've only tested this particular problem with the Microsoft.UI.Xaml.Controls version of tree view and in my particular app. But since the Windows.UI.Xaml.Controls version had the same grid view data template problem noted above in a simple problem demonstration app, I suppose this treeView.RootNodes.Clear() problem exists in that version as well.

[tmr4]

Some possible work arounds for the above problems (ones I've implemented, other solutions may be possible):

1. first grid view item of child node isn't displayed until moussed over. Solution: remove data binding and manually set the contents of the grid view items.
2. child nodes rendered out of order after expanding a second time. Solution: when collapsing a node collapse the inner most child first and proceeding outwards, collapse the next children in the hierarchy until all child nodes are collapsed before collapsing the desired parent node. This works fine when done manually but I've had limited success implementing it programmatically. It seems some internal TreeView processing is required after the expand/collapse chevron is clicked which doesn't happen when collapsing child nodes programmatically one after the other. As a work around I have each click on a parent node only collapse the inner most child, thus a node with nested children three levels deep would take three clicks to collapse the parent node. A bit cumbersome, but it works for me.
3. treeView.RootNodes.Clear() doesn't internally clear out a TreeView with a GridView based data template. Solution: destroy and recreate original TreeView.

[tmr4]

An update to #2. child nodes rendered out of order after expanding a second time. You can collapse the children nodes programmatically, but need to do it on a non-UI thread and give the UI time to completely process the child collapse before collapsing the next child in the hierarchy. I found that providing a one second delay between collapsing nodes was sufficient. Half a second delay wasn't enough and resulted in jumbled nodes on expanding again.