ListViewBase Header Behaviors Port #136
Conversation
|
Opened #137 for tracking the UWP head issue, not introduced in this PR or the other one, so we'll investigate later. Didn't have a chance today to finish looking into clean-up for this. Will take a quick look in the morning and test on WASDK head. Once this is merged, I can finish the DataTable PR in Labs and will see if I have issues referencing UWP Behaviors package there in samples... |
|
Clean-up is looking good here, have a base class for all three Header behaviors now that does the heavy lifting of finding the required elements. Then going to see if I can flip the paradigm a bit to simplify the code a tiny bit and also enable it for other scenarios with just |
|
Making the element to attach to be the Last test will be to see if it'll work with anything that's within a Could also mean we could attempt to try with the |
|
Footer scenarios need all new math, so maybe it's just easier to have different classes (with different names) for those that work from the bottom up. Could change the base class though from 'HeaderBehaviorBase' to 'ScrollViewerCompositionBehaviorBase' though (albeit it's wordier, it's more accurate)... Everything is working except the QuickReturn in the new scenario on first load (if I change tabs and comes back it works fine), building all the samples so I can test if it's a WASDK quirk vs. UWP (need all due to #137) |
|
Ugh, I can't test if it's a UWP issue with QuickReturn in ScrollViewer due to CommunityToolkit/Tooling-Windows-Submodule#100 Edit: Maybe I can swap it with a rectangle for now to test quick locally... |
|
K, was able to test locally in UWP with a rectangle, doesn't work. So, it's something specific to the initial load vs. subsequent usage... will need to investigate, but maybe will just file an issue since it's a new scenario. It's cool when it works though! |
Add doc and Samples showing for ListView, GridView, and HeaderedTreeView Tested on WASDK (uses composition, so won't work on Uno) Having issues with UWP head?
…ew abstract HeaderBehaviorBase helper class Is responsible for finding needed controls and properties for setting up composition animation. 90% of these two classes were doing the same thing, so now only the logic related to setting up/manipulating the composition animation is in each subclass. Going to investigate if FadeHeaderBehavior is similar enough to reuse as well.
Was much more aligned then it looked at first glance. Think it was first, so some things were just done locally in scope vs. cached from the other classes. At least now we can clean things up all together easily if we want to optimize things. Main difference is some of the event hooks, so if they're not needed we may want flags/options for those in the base class to enable.
…e that everywhere anyway...
…enable more scenarios
…new scenarios enabled by changes Show a HeaderedItemsControl with a StickyHeader Show a QuickReturn of an element that's at the top of a ScrollViewer (doesn't load properly on first load though??)
ae2ea78
to
6033436
Compare
|
Weird... same issue that happened on #140 (comment) but on the WinUI 2 pipeline vs. 3... |
|
This may have been effected by CommunityToolkit/Tooling-Windows-Submodule#96 - probably didn't notice as I was testing the samples maybe? Can't remember. Either that or it's a regression? |
|
Minor design tweaks to the samples: #142 @michael-hawker While testing this, some observations:
|
|
@niels9001 see #137 there's some weird issue with the Behaviors UWP head, building the entire sample app works fine. I didn't touch anything with the auto focus behaviors. They don't work in the existing Toolkit app either, so I'm thinking maybe the OS broke these or something? @vgromfeld is this anything you're aware of? The Header behaviors won't work on WASM (or Uno) as they all use composition, so that's expected. Maybe should call that out in the docs, eh? |
* Design tweaks * Removing background theme brushes
We're not aware of anything on our side. I realized that we're still using our initial implementation from before our contribution to the toolkit (😓) but the two implementations are the same. We do not have any issues on our side within an UWP project. |
Co-authored-by: Michael Hawker MSFT (XAML Llama) <24302614+michael-hawker@users.noreply.github.com>
|
@niels9001 did I address your questions? We good for this? (Want to add it to at least an existing sample on the DataTable before trying to merge that.) |
Requires #121
Fixes #112
Needed for CommunityToolkit/Labs-Windows#418
Brings over the
StickyHeaderBehavior,QuickReturnHeaderBehavior, andFadeHeaderBehaviorfrom the Toolkit missing in the original port. Adds a sample for each built uponListView,GridView, andHeaderedTreeView.Having issues building UWP head for Behaviors component though... WASDK worked fine, no obvious error message in build output, will see if CI highlights anything different...
StickyHeaderBehaviorandQuickReturnHeaderBehavior...Headerinstead so it can work with basically anything in aScrollViewer?