While discussing the problem with WPF people at TechEd, I showed a Microsoft employee this question. He was nonplussed.
We downloaded a tool which interrogates WPF layouts and identified the container as the "Virtualizing Stack Panel" element in the ListView.
In a followup email, he wrote: "This is the fault of VirtualizingStackPanel. I’ve opened a bug about it. Hopefully it can be fixed in a future release. The workaround (using StackPanel) should be fine for now, as long as you don’t need the ListView to virtualize its content.
The bug involves a step in VSP’s Measure algorithm that remembers the largest size ever discovered and forces all future Measure calls to report a size at least as large. In your case, the VSP is initially measured before any triggers have fired, so it computes the size as if everything were visible. When the triggers fire and collapse the buttons, the measure algorithm computes the correct (small) size, but then forces the result to be large again. The comment says something about avoiding unnecessary re-layouts while scrolling, but the code is running even when there’s no scrolling going on."
The work-around involves re-templating the ListView with this code:
<ListView.ItemsPanel>
<ItemsPanelTemplate>
<StackPanel/>
</ItemsPanelTemplate>
</ListView.ItemsPanel>
This caused the list behavior to work as desired, but it carries the disadvantage of not having the memory management capabilities of the VirtualizingStackPanel. For my use, this was appropriate; the list items are never going to exceed 2000 or so at one time.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…