Changing the language of a window breaks displaying child nodes of a TreeView
Bug explanation
Changing the language of a window breaks displaying child nodes of a TreeView. I assume it has something to do with an UI update because it breaks in another app when different TreeViews are displayed. The only way I can reliably reproduce the issue is with the language change.
Here is a video demonstrating the issue. I also uploaded an example app.
https://user-images.githubusercontent.com/31562861/229203111-cf8afc11-aac1-4830-878d-4d41ee21e4e9.mp4
Using Snoop I figured out that this binding breaks as it somehow references the wrong ItemsHost element.
I temporarily fixed the issue by changing the line from
<Binding ElementName="ItemsHost" Path="ActualHeight" />
to
<Binding RelativeSource="{RelativeSource Mode=Self}" Path="Children[0].ActualHeight" />
I don't think that is the proper solution though.
Version
4.6.1, 4.8.0
@reiseder Great work on writing up a sample app and even pinpointing the binding that fails!!
I had a quick look at it, and it really is strange what is going on. As you mention, once the language changes, the binding seems to point to a "wrong" ItemsHost element. A funny thing to note, which I think your video also captures, is that even in the scenario where you expand the node and nothing shows up, you can still make it magically show up by toggling the language again. That seems to make the "original" ItemsHost re-appear and the binding kicks into play again.
I cannot really explain what is happening, nor can I come up with a better solution that what you posted as a temporary fix. I agree it does not look ideal, but it seems to solve the issue and it's not THAT bad.
Perhaps @Keboo could have a look at this and educate us on what is actually happening? Why are ItemsHosts being swapped out causing the binding to break? And how come you can "bring it back to life" by toggling the language again? Questions I personally would like to know (and understand) the answer to.