Fix crash with UniformGridLayout trying to scroll to first item #2969
Conversation
msft-github-bot
added
the
needs-triage
|
Also, does #2812 have the green light? During this PR, I wish there was some form of documentation on how those areas work together as the stacktrace can be quite long and go through different areas of the ItemsRepeater control. |
| if (const auto firstElement = context.GetOrCreateElementAt(0, winrt::ElementRealizationOptions::ForceCreate)) | ||
| { | ||
| firstElement.Measure(availableSize); | ||
| hasCachedSize = true; |
There was a problem hiding this comment.
hasCachedSize [](start = 20, length = 13)
If size change after the first measure, we will not update the size of all the items. This is a change in behavior with this change because of the caching here.
There was a problem hiding this comment.
I've changed the code now to always realize if FlowLayout did not do that. Is there anything else we need to consider here?
StephenLPeters
added
area-ItemsRepeater
team-Controls
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I used ItemsRepeater with UniformGridLayout as layout and I faced the same issue as mentioned below in Winui 3 preview 3.
"Itemsrepeater's child not found in its children collection." Is this fix reflected in the Winui 3 preview 3 release? |
Description
The issue is that we didn't managed to properly recycle the first item, even though the UniformGridLayout was the owner. That resulted in the ElementManager trying to move ownership to realize that it isn't the actual owner, which resulted in the crash.
The behavior changed to only cache the item's desired size (which is the only information we needed), and let the ElementManager take care of managing.
Motivation and Context
Closes #535 and closes #2834
How Has This Been Tested?
Add API test for #2834, tested #535 manually (code not included in this PR)
Screenshots (if appropriate):