fix: CalendarView selection near end of entire calendar #17722
Conversation
| global::System.Diagnostics.Debug.Assert(index >= 0); | ||
| global::System.Diagnostics.Debug.Assert(pHost.Panel is { }); | ||
|
|
||
| #if HAS_UNO_SKIA || __WASM__ |
There was a problem hiding this comment.
I can't find any usages of HAS_UNO_SKIA, what directive do we use for platform specific skia code?
There was a problem hiding this comment.
We'll need to add tests for this scenario.
There was a problem hiding this comment.
I can't find any usages of
HAS_UNO_SKIA, what directive do we use for platform specific skia code?
__SKIA__ should work. Though I think this is ported code, so unclear why it needs to change
There was a problem hiding this comment.
Also note that the current offset looks correct, but the issue is in the "blank" area. It should contain months from the previous year.
The repro steps in the issue showed that it rendered correctly one time, then it no longer renders correctly.
Correct:
Wrong:
There was a problem hiding this comment.
After digging into this further, I'm not sure what fix/workaround would be best.
This is the behavior for the UWP CalendarView:
If we compare to the current version @Youssef1313 you are right, the indices are correct it's just the space above that needs to be filled in on other platforms.
Here's where the bounds of the scope of items in the current calendar view are set. If we could decrease the FirstVisibleIndexBase, more items would be visible and would fill the gap of this issue.
uno/src/Uno.UI/UI/Xaml/Controls/CalendarView/CalendarView_Partial.cs
Lines 1840 to 1841 in 4ad6ef3
These indices FirstVisibleIndexBase and LastVisibleIndexBase are set via code that bubbles up from here:
uno/src/Uno.UI/UI/Xaml/Controls/CalendarView/CalendarLayoutStrategyImpl.cs
Lines 183 to 186 in 4ad6ef3
I thought I would be able to replicate the changes in this PR in the piece of code above but I've had no luck so far. Everytime we switch from the decade view to the year view the FirstVisibleIndexBase increases for some reason I haven't been able to find, leaving even less items visible.
There was a problem hiding this comment.
@dr1rrb Does that sound familiar?
There was a problem hiding this comment.
Not really ... I remember that we already did fixes for the month / year / decade switching, but I'm unable to remember what is was, we need to look at git history.
|
🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-17722/index.html |
rajamatt
force-pushed
the
dev/mara/fix-calendarview
branch
from
47b31bb to
9e7ef9f
Compare
|
🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-17722/index.html |
|
🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-17722/index.html |
|
🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-17722/index.html |
|
🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-17722/index.html |
|
The build 134460 found UI Test snapshots differences: Details
|
|
🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-17722/index.html |
|
🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-17722/index.html |
GitHub Issue (If applicable): closes #17635
PR Type
What kind of change does this PR introduce?
What is the current behavior?
What is the new behavior?
PR Checklist
Please check if your PR fulfills the following requirements:
Screenshots Compare Test Runresults.Other information
Internal Issue (If applicable):