Itemsrepeater fixes and scroll anchoring #4091
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To diagnose problems with `ItemsRepeater`.
The default value needs to be the same as the default value in the associated `ItemsRepeater` properties.
Hack was added when porting `ItemsRepeater. Not sure it's needed anymore.
`ItemsRepeater` doesn't work properly with a 0 cache length.
`OnEffectiveViewportChanged` needs to be triggered first, otherwise `_makeAnchorElement` is cleared too early, breaking scrolling in a list with variable-height items.
So one can see their bounds easily.
Instead of simply reading old `TranslatedBounds` value when `Bounds` changes, use the clip and transform from the previous `TranslatedBounds` with the new `Bounds`.
On `ScrollContentPresenter`.
When a layout of a control exceeds the maximum passes and we re-queue it, reset the attempt count to 0 because otherwise it can end up stuck in the layout queue forever even when the next layout can succeed with e.g. 2 passes. This can happen with `ItemsRepeater`.
When `Offset` is adjusted due to scroll ancoring during the arrange pass in `ScrollContentPresenter`, don't invalidate the arrange: we've got it handled.
- Change the hack we're using to find the effective viewport in `ViewportManager` - Unregister anchor candidates when bringing an item into view - Adjust `ScrollContentPresenter` extent when tracking an anchor, if the adjustment causes the offset to go out of bounds of the extent - Simplify coercing `Offset` in `ScrollViewer`
And don't call `OnEffectiveViewportChanged` if viewport unchanged.
Instead of using `ScrollContentPresenter.Viewport` which hasn't been updated yet.
`ScrollContentPresenter` now coerces offset so it can only be set after a viewport has been calculated.
- Make sure an anchor is a descendent of the `ScrollContentPresenter` when added - Ignore controls that are no longer descendents of the `ScrollContentPresenter` when evaluating
When we set the DataContext, we save that fact in the VirtualizationInformation for that element, when that element gets cleared, we look up in the VirtualizationInformation whether we should need to clear the DataContext too, and do that if necessary. Ported from microsoft/microsoft-ui-xaml@e9bd88e
We need to return the max of the bounds and the constraint, otherwise horizontal/vertical alignment doesnt work correctly.
|
This hasn't fixed all the problems with |
jmacato
approved these changes
Jun 20, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does the pull request do?
Trying to fix issues with
ItemsRepeater:ScrollContentPresenteretc behavior mirror that in UWP and adding a new hack to work around the lack ofEffectiveViewportChangedeventScrollContentPresenterChecklist
Depends on #4080