Yes, you'd only be able to resize them in the header not at any individual item level. I can add that as a clarification in the list. Think that's the other trickiest bit of this setup is to figure out how that works, responds, and is created 'dynamically' based on the number of desired columns.

I had tried adding a GridSplitter into the header Grid, but that caused the UWP side to crash (no idea why, worked in WinUI 3). And only the layout for the header gets modified, so the columns in the table don't auto-adjust. Trying to detect that layout update from the child seems impossible, as I think LayoutUpdated is the only hook, and that doesn't have the right timing and would cause a Layout cycle...

So, I think for resizable columns (as well as just making the paradigm easier to setup/use/manipulate) we'd have to have the parent DataTableHeader control to coordinate with.

Indeed the default ListView/ItemsControl headers will scroll with the content. Though we already have our header behavior helpers, like the StickyHeaderBehavior which should work here just the same: https://learn.microsoft.com/windows/communitytoolkit/behaviors/headerbehaviors

We'll want to make sure we bring these behaviors over to the new setup sooner than later anyway. Taking a quick look at their code again, they could maybe use a bit of a revamp, maybe share some common base as well as be tweaked to work for ItemsControl/ItemsPresenter based controls vs. just ListViewBase?

Initial PR here: #418

Thanks for looking @dhoehna, you should just have the context of the whole row as it'd be in a standard item template for a ListView, so if you needed to pass in the context of the row to a command let's say, it could be something like this:

        <ListView.ItemTemplate>
            <DataTemplate x:DataType="local:InventoryItem">
                <controls:DataRow>
                    <TextBlock Text="{x:Bind Id}" />
                    <TextBlock Text="{x:Bind Name}" />
                    <TextBlock Text="{x:Bind Description}" />
                    <TextBlock Text="{x:Bind Quantity}" />
                    <Button Command="{Binding ViewModel.DeleteCommand, ElementName=MyPage}" 
                            CommandParameter="{x:Bind (local:InventoryItem)}" 
                            Content="x"/>
                </controls:DataRow>
            </DataTemplate>
        </ListView.ItemTemplate>

If you're just using the Button.Click event, then the DataContext I believe should be the item row as well (or easy to get from the source event args). We should definitely have some samples to show these sorts of things with this paradigm.

Thanks for the feedback @jhert0! What type of Row styling would you be looking for, could you provide a couple of examples and/or images or examples?

For an aggregate row, I think re-using the DataRow within the Footer could work, would just need to be tested. Would make a great sample/example for sure. We'd still leave the actual aggregation/binding up to the end developer though, as there could be different logic needed by column here (count vs. sum vs. avg, etc...)

I think at most for Sorting we'll support displaying a glyph on the column and keeping track of the desired direction for you and then again needing to have the developer in the click event sorting the source of the ListView. We'll certainly have a sample which shows this though as we know it'll be a common scenario.

Being able to change the background color of the row based off a value in the row itself. Something like how the current DataGrid does row styling would work. We do a lot of color coding in our DataGrids depending on the status of the record. Like for example if something is past due, we would change the rows background color to red. Alternate row background/foreground color is another example, I'm not sure if that would be possible but would be nice. I think borders would work as an alternative if that isn't able to be implemented.

I think it would be nice to have a built in way to automatically do sum, count, and average, like the Telerik DataGrid has a control specifically for aggregates with count, average, etc. setup as functions that you specify. It wouldn't be the end of the world if that's not possible or can't be done right now. Here is a link to what I'm talking about with the Telerik DataGird: https://docs.telerik.com/devtools/winui/controls/raddatagrid/aggregates/datagrid-propertyaggregatedescriptor

To clarify, you're talking about having a fixed number of rows and every data item is a new column going to the right, eh?

Was thinking a bit about Orientation and how something like that could be supported or not. Would need to play with this setup a bit more first once we figure out column resizing to know more.

Considering you can change the orientation of items in a ListView as well, I don't see why applying a similar technique would be too much different, just not sure if the structure in XAML to support it would be the same or need differences to make it compatible or if it'd need to be something else.

To clarify, you're talking about having a fixed number of rows and every data item is a new column going to the right, eh?

Yes. Thanks for taking this into considaration.

I totally agree with this.
People will start to use this, notice that things DataGrid has are missing, complain about it and then it eventually gets added.
In the end you have two DataGrid classes that have to be maintained.

Good points, but I don't know if folks realize how huge DataGrid is. It's its own project, probably bigger than most of the rest of the controls of the toolkit combined.

DataGrid is 40,000 lines of code (and I don't remember if I included XAML styles in that count or not)...

It was brought into the Toolkit by another team based on the Silverlight port (which I think was a WPF port too) from the original control written like a decade ago. Lots of things have changed in that time in terms of code, best-practices, usage, design patterns, etc...

The main idea here is that we can leverage the inherit code that does a lot of the base tasks (like selection and virtualization) inherit to ListView with a bit of extra helpers to enable many of the DataGrid scenarios.

The POC so far is under 500 lines, and even with some extra helpers and such for some of those extra scenarios will still be a lot less complex than the ported decade old code of the original DataGrid. Something much more maintainable and flexible for a variety of scenarios. For instance, this new method may work with a TreeView as well (need to test that) which would easily enable a TreeGrid type scenario without really any extra code in this method. However, to enable that scenario in the current DataGrid would be a massive undertaking instead.

So, it's really about using this experiment to see what's possible with some additional helpers and leveraging smarter paradigms and how we use existing components and the framework to enable this scenario. Then figure out how things compare and what makes the most sense moving forward for the majority of folks that need these scenarios. Yes, they may not be compatible or easy to switch between, but that may not be a problem for the majority of people.

I do agree. This is super relevant especially if existing DataGrid documentation isn't improved. I can imagine people using DataGrid. Spending a huge amount of time trying to get simple tweaks to work, then giving up and not looking for a better option.

I would be okay with this POC if the documentation also changed telling people to use this instead of DataGrid.

And we have 'TreeTable' working! 🎉🎉🎉 FYI @niels9001 @Arlodotexe @YegorStepanov

Works well with the 'auto-sized' column feature I got working earlier, added a ColumnSpacing property to DataTable as well to help with mashed together text on the right-side of the Id column and the left-side of the name.

For now, dealing with various padding difference between the containers manually with Margin on the DataTable... think we could maybe try and use an Offset property to do as part of layout and maybe detect, but for now manual seems easiest for the POC.

Thanks @robloo for the insights here. An attached property to replicate this is an interesting idea, but don't think that'll work the same way, as in WPF the base components are built with this pattern in mind. As far as I know, UWP has no support for different view modes like WPF had to make ListView display as a table, otherwise, we wouldn't need any of this.

Here we would need to modify/inject things into how layout is performed and still have things as part of the visual tree. Trying to do it with configuration and templates to replicate the WPF syntax would require a lot of injection and manipulation of the tree manually vs. exploiting and leveraging what ListView is already trying to do with the base setup folks use for this pattern normally.

It could be possible to investigate subclassing ListViewBase with a custom style and doing more of that route, but then that's specific to one component and probably harder to maintain if ListViewBase gets updated. The current approach looks for the common ItemsPresenter across these types of controls (ListView, TreeView, HeaderedItemsControl, etc...) and leverages that common point to coordinate layout.

Will take a look though for naming conventions and patterns to see what makes sense to leverage from the historical context though.

@michael-hawker Good question.. what about the last columns always set to star and the other columns to auto? I think that's what e.g. File Explorer does. I'd expect the dev to override that in case that's needed?

Hmm, not sure how complex that'd be to detect, I'll have to take a look. Need to investigate what's shutting off container virtualization though...

Virtualization is working on the control great, this was a quirk of our sample system and the outer ScrollViewer giving it infinite space so the inner ListView as attempting to be rendered in full (instead of taking over the viewport and allowing for virtualization to occur).

For Auto columns... I realized that the layout pass is occurring with Measure and Arrange both on the DataTable before Measure on the DataRow...

Was originally expecting for both Measure steps to occur first... Makes things a bit more complicated, so need to figure out how to invalidate the Arrange for certain components in certain scenarios... Don't think I need to retrigger Measure again anywhere once something's been measured once.

This is only for the Auto scenario though, so will be an optimization note that using Auto is more complex than having Fixed or Star sized columns. (Which I knew was the case, but should remember to add a footnote in the future docs about it.)

Have some ideas, but think need to get the better 'pipe' between the DataTable and the DataRow setup first, as that should help with whatever solution ends up working best.

Currently, my hacked together invalidation almost works, but the first row isn't laid out properly. I think it's because the lower row is actually the one that causes the increase, so I need to re-Arrange that other first row... which nothing is telling it at the moment (was hoping re-triggering Arrange on the DataTable may do that). Hard to test this with so many instances of DataRow, maybe need to try a simple scenario. Funny thing is the test I wrote passed, but I believe it was only testing a couple of rows, so may need to improve the test too...

Would the last column be non-hit tested, to allow for drag selecting of rows?

DataGrid is from WCT though.

Yes, but DataGrid was contributed and maintained by the platform team initially.

Will this have support for reordering columns at run time?

As so with virtualization if I make something really long out of view:

It'll grow when it gets close:

(need to test the behavior for sticky header too still and make a sample)

But virtualization remains fine only keeping the 40 or so item containers in memory. 🎉

Think this means we're good on the virtualization front and how auto-sized columns should behave by default.

Just need to get the resizing bit in there to convert them from auto to fixed, and provide a way to reset it maybe... how that all ties together is the next challenge I think! Will go push my current code though to my branch.

Will this have support for reordering columns at run time?

@yaira2 No, that's not in the initial plans, just allowing columns to be hidden and resized.

I still don't understand how to make a custom panel that behaves with Drag and Drop... I don't think it's (well?) documented??

If we learned how to do that, then that would make it more feasible. Otherwise, it'd be left up to the developer to have a dialog with a list to allow selecting/re-ordering columns and then just manipulate their data source collections and such.

That'd be easier if DataTable supports a source for a column collection I suppose over needing them defined directly, but that adds more complexity there too, as then we'd basically just be inheriting from ItemsControl or a ListViewBase at that point... It also means something similar for DataRow as all the UI elements are defined together too.

Overall, it's not a scenario that is built-in with the plan of this approach and how it works.

That's the pitfall with this approach, it's not a lot of code to get where we are and provide a lot of value for some core scenarios, but we may hit cliffs where if we want to do something it's not going to be worth tacking more on vs. needing to look at an alternate solution.

Great question though, added it to the list of differences though for future tracking/awareness.

Was thinking since we coordinate already between the DataTable/DataColumns and the DataRow we can always arrange the child items in any order that we desire. So, shuffling the contents within the items based on a re-ordered list of columns doesn't seem that complex at the moment (assuming there's a defined mapped correlation setup between them at the start before a re-order event).

The main issue still becomes how to allow for drag/drop behavior and ordering of the parent columns within the DataTable panel itself, and the lack of knowledge/documentation around enabling drag/drop for custom panels.

Would the tapping + chevron be enabled/disabled by default? IsClickEnabled (default: false?) or something like that?

Maybe setting the sizer to the right of the column is the simplest way and consistent with File Explorer? You'd typically resize the first column at the right to show more of the first item?

WWED? (What Would Excel Do)

Column separators on the right impact the size of the preceding column.

Yeah, File Explorer and Excel behave similarly in that regard. Main thing is behavior for the last column, but like most things going to depend on the scenario, so basically going to end up left to the developer adding to their app and whether they have columns expanding or resizing, etc...

Thanks @davidegiacometti, appreciate the feedback. DataTable is an early prototype, we definitely hadn't implemented all the places for visibility and having a story there for hiding columns or data in columns.

We hadn't tested tab focus yet, so could be something going on there in the header, but not sure what.

I believe I've hit the small resizing issue, but don't remember what it was, one of the calculations zeroing out I think maybe.

I think our sample has a star-sized column in the middle. What do you mean by "doesn't work well", what is the behavior you're seeing and what do you expect?

Feel free to test anything out in the DataTable experiment directly as well and open a PR if you want to try and fix any of these things. The code is fairly minimal for this (part of why we went this route). I've added a few comments, but happy to elaborate or point out on anything or how it works. Thanks!

Nice to know that visibility and tab focus are still under work 👍

For the star-sized column what I expect is that the star-shaped column takes up the entire available width and that the following columns are visible.

I have been able to repro the issue with the DataTableSample.xaml and it's reproductible when DataColumn has no Content set.

<controls:DataColumn DesiredWidth="80" />
<controls:DataColumn MinWidth="120" />
<controls:DataColumn DesiredWidth="*" />
<controls:DataColumn DesiredWidth="100" />

Working as expected

<controls:DataColumn DesiredWidth="80" />
<controls:DataColumn MinWidth="120" />
<controls:DataColumn DesiredWidth="*" />
<controls:DataColumn DesiredWidth="Auto" />

If I change the Quantity column to DesiredWidth="Auto", the column is not displayed.

oh, adding a width property fixed issue

Thanks for giving things a try and providing feedback @zsolt3991. I would expect the layout to be squishing and resizing the available space for the TextBlocks, so could be something going on there that's unintended.

There's not too much plan currently with DataTable besides experimenting and gathering feedback at the moment. WinUI has announced they're looking at a TableView for 1.5; so we're also coordinating with them on what that's going to look like, as that will most likely supersede the work being done here.

microsoft/microsoft-ui-xaml#1500 (comment)

Did a quick look at switching DataTable to ListViewBase, thought there'd be an issue with adding styling and overhead there, but we already style DataColumn, so we've already incurred that cost.

The main other thing right now is that DataRow looks for Panel as it can also try and use a regular Grid to coordinate against in the Header. Though there's no commonality between ListViewBase and Panel, so it means we have to duplicate code to still support a regular plain Grid in the Header or remove the hybrid scenario... hmmm

I wish I could help ya in this ;n;