🧪 Modern/Lightweight 'DataGrid' - Introducing DataTable

[michael-hawker]

DataTable

Initial PR: #418

Problem Statement

A lot of times app developers want to display a denser set of data, usually in a grid type format with multiple rows of items that have particular properties (e.g. an Id, Name, and Description).

Generally, this forces a developer to go from something more light weight like an ItemsControl or ListView to look at a full-blown DataGrid control, even if they don't need all its capabilities for sorting, editing, selection, customization, etc...

This adds a lot of complexity and overhead to an application where a more custom-built solution may do. However, it's hard to recreate this look without just nesting a bunch of Grid panels together.

A main feature that a lot of these UIs do want to provide users though is the ability to resize columns. This is also hard to make work with a bunch of nested Grid panels without just moving to a DataGrid as well.

Inspiration

We see a lot of these patterns come up where a DataGrid is just overkill for the desired scenario, especially when:

• a simplified/modern style is sought after as more of a 'Table'
• cell selection isn't needed
• editing of everything isn't required
• only resizing of columns is really what's wanted

But there's no go-to for these scenarios, there's just, use lots of static Grid elements, make something custom, or DataGrid.

Proposed Solution

Imagine we had a way to coordinate the layout of all the items within an ItemsControl or ListView. We'll call this our DataRow, then we could have a single DataTable that we use as a Header in order to manipulate each column's size as a whole.

<ListView ItemsSource="{x:Bind MyItems}">
   <ListView.Header>

       <!-- The Controller contains definitions for each column, how it should be sized, and controls resizing -->
       <ct:DataTable>
           <ct:DataColumn Content="Id" IsResizable="False" DesiredWidth="100"/>
           <ct:DataColumn Content="Name" DesiredWidth="Auto"/>
           <!-- Each column can be text or quickly customized by containing any content or restyled of course -->
           <ct:DataColumn MinWidth="300">
               <TextBlock Text="Description" FontWeight="Bold"/>
           </ct:DataColumn>
       </ct:DataTable>

    </ListView.Header>
    <ListView.ItemTemplate>
        <DataTemplate x:DataType="local:MyItemType">

            <!-- The DataRow panel automatically lays its items out horizontally but based on the horizontal size of the 'parent' DataTable control panel -->

            <ct:DataRow>
                <TextBlock Text="{x:Bind Id}"/>
                <TextBlock Text="{x:Bind Name}"/>
                <!-- Light-weight editing can just be setup by a developer however they need it for their scenario, could use something like a SwitchPresenter even to flip between edit and non-edit modes for a value.  -->
                <TextBox Text="{x:Bind Description, Mode=TwoWay"}/>
            </ct:DataRow>

        </DataTemplate>
    </ListView.ItemTemplate>
</ListView>

This would also just work the same for an ItemsControl if row selection wasn't needed.

Comparison to DataGrid

Benefits/Comparison over DataGrid:

• Easier to use/more intuitive to setup/customize as using base XAML building blocks without complex templating/styling
• Therefore Styling/Look-and-feel much more in developer's control, based off common controls
• Usable with ItemsControl (static) and ListView (for selection)
• Grouping should just be provided by ItemsControl itself
• More light-weight of a component in-general for Visual Tree
• Support row virtualization via ItemsStackPanel (should containerize on the datatemplate, unclear if WCT DataGrid supports virtualization)
• Still provides column resizing via header (would use one of our new splitter controls built-in to the DataColumn component).

Limitations compared to DataGrid is that:

• No Row Headers (would just be part of developer's DataTemplate for each item)
• No Built-in Cell Editing (But you can toggle editing on your own with existing techniques like for TextBox/TextBlock, etc...)
• No Built-in Cell Selection (But you could turn off selection in the ListView or use ItemsControl and then make a 'selectable' container/background wrapper for every control in your coordinated panel, could think of DataCell helper in future?)
• No Built-in Sorting (But you could add something to your header content and then just sort the underlying collection, know we need a better sorting/grouping all-up sample. I know @Sergio0694 has part of one in the MVVM sample app. Also, you had to do this on your own with DataGrid anyway)
• No Detail Template (Doesn't mean you can't pop something up on selection though, just may not be inline or elsewhere in the layout)
• No Grid lines (though could use a border around elements or what not, ties into potential DataCell helper in future)
• No Column Reordering (Users can't drag-n-drop columns with this setup, think that's a hard issue here, unless we maybe learn how a custom Panel, in general, enables drag-n-drop... I've never seen an example or a doc on this topic...). Also, how would items know the order? They'd have to arrange differently, which should be possible since we use a custom panel, but we'd have to keep track and map that across columns.

Technical Breakdown

First, why not ItemsRepeater? ItemsRepeater is powerful, but also more complicated to use and build Layouts for. This approach for the experiment gets us to a prototype faster and should be easier for developers to consume. It also allows for both usage with the light-weight ItemsControl and ListView and with row/container re-usage should still support virtualization those controls provide as ItemsStackPanel would still be used.

I don't think a singular panel on the ItemsControl/ListView to handle this would work well. First, it would still need to know how columns are defined. Second, each item's data template still needs to be contained within some Panel anyway and the DataTemplate is what takes the item and 'splits' it into each individual piece of data for a column.

By using the fact we need a Panel in our template, we can use this to easily create this mesh of panels that are all tied to a single controller by walking up the Visual Tree. If x:Bind could break out of the template that'd be more direct and performant, so resorting to run-time Binding anyway means we might as well just do this step for the developer vs. having to explicitly 'link' them together (unless there's scenarios to be used outside of an items based control, so it should still probably be supported if set by the developer as a short-cut to the logic).

When initialized, the DataRow will walk and get the reference to the DataTable to register itself. It will use the restrictions and current layout info from the Controller to lay itself out in a simple measure/arrange setup of the DataRow.

We will have to be wary of layout cycles and reducing creating extra ones as well. I'm hoping that when a controller column is resized, we can use the ending of that event to invalidate the layout all together and hopefully already know the specific sizes we desire each column to be. This is going to be the trickiest part of this setup and is going to require some investigation and fiddling with to understand and 'coordinate'. (Thus, the reasoning for the original naming.)

Open Questions

• Is this a good name/pairing? (edit updated above to be DataTable, DataColumn, and DataRow)
• Are we missing any common scenarios (i.e. beyond grouping/sorting/customization) that we think this pairing should handle directly or at least we should have a sample for?
• Would you ever need to resize rows only and not columns? i.e. Transpose the whole layout/orientation and have a fixed number of rows and columns as the items? (Maybe we use DataHeader over DataColumn as a name just in case or for a future revision?)

API Reference Docs

• WCT DataGrid
• WPF ListView.View
• General 'Lists' style UI guidance
  • List/Details
• https://learn.microsoft.com/windows/uwp/debug-test-perf/optimize-gridview-and-listview
• https://learn.microsoft.com/windows/uwp/debug-test-perf/listview-and-gridview-data-optimization
• WPF's SharedSizeGroup

References

• x:Bind outside data templates is extremely inconsistent microsoft/microsoft-ui-xaml#2508
• https://stackoverflow.com/questions/41757710/uwp-listview-with-responsive-columns
• https://stackoverflow.com/questions/35235692/uwp-xaml-listview-with-header-and-datatemplate

[niels9001]

@michael-hawker With the proposed solution, would that mean that resizing columns can only be done in the header and not in the ListViewItems? (Which I think is totally fine.. and inline with what the OS does 😊)

[michael-hawker]

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.

[michael-hawker]

Ah, forgot about these two Uno Issues for WASM:

• [WASM] Listview header and footer are not implemented unoplatform/uno#1979
• Add support for ItemsControl Header and Footer unoplatform/uno#10745

Could pose a problem for this solution working with Uno, at least on Web Assembly.

[michael-hawker]

Hmm, if this all works, we could maybe extend the DataTable panel in the ItemTemplate to have a Header/Footer paradigm as well where it will arrange that above/below the rest of the contents as it's own 'row'. And give them visibility properties. Then developers can just bind/toggle the visibility property on a particular item to act as row details? 🤔

[michael-hawker]

Initial prototype looks promising, have the initial panel-test for DataTable setup and working with the 'standard' Grid paradigm (with the new HeaderedItemsControl, also here):

In branch: https://github.com/CommunityToolkit/Labs-Windows/tree/llama/datatable

Need to decide if we want to keep this interop-hybrid compatibility with Grid or not and how much extra overhead that would need vs. just having the interop with the common helper control (to be built still).

[michael-hawker]

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.

[Psychlist1972]

This really looks promising. I like that it has virtualization. Do the headers remain in place when scrolling like they do on a DataGrid? That's something that regular repeater/items controls don't do by default. Resizing would also be nice :)

This page originally had a DataGrid, but I removed it for all the reasons you know. There's a lot of datatemplateselector cruft happening right now to handle the display of different message types on the right. That (or some equivalent code alter) would need to be there regardless of control used.

Pete

[michael-hawker]

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?

[michael-hawker]

Well, have very initial prototype together (ListView padding of item throws the alignment of headers a bit off, to do item):

Has basic structure using new DataTable panel (containing DataColumn definitions) and the DataRow helper for the item templates.

Makes defining columns super simple, but familiar/similar to Grid's ColumnDefinitions as it uses same GridLength type and the DesiredWidth property on DataColumn. DataColumn can contain any custom content instead, if desired.

DataRow automatically coordinates the layout with the top header.

Still to be explored:

• Putting a sizer control on the header columns to allow user-resizing of columns dynamically (switch to Control over ContentControl for DataColumn and make XAML templated)
• Proper 'Auto' sizing based on content within the rows (right now uses size of column header, which wouldn't be expected)
• Handle infinite layout edge cases
• Lots of clean-up, samples, testing (grouping, virtualization), etc...
• Have an idea for row details support in the DataRow panel with a Header/Footer properties and IsHeaderVisible/IsFooterVisible properties devs can tie-in to as they require, then just modify the panel's height arrangement if those are true to include the measure/arrange for the Header/Footer

[michael-hawker]

Initial PR here: #418

[dhoehna]

This is nice solution between DataGrid and an ItemsRepeater. I do like that each cell does not need its own cell template. I also like that I can add borders to cells.

One request. This request isn't a deal breaker.

I have a grid with buttons in the rows and on the button click I need the context of the row. DataGrid's args was the object the button was clicked on.

With an ItemsRepeater I need to declare the context in each button.

Example.

The click handler of the two buttons needs to know the object it was clicked on. DataGrid did this automatically.

In an ItemsRepeater I need to do the following in XAML.

     <Button.DataContext>
       <models:CloningInformation 
           ProviderName="{x:Bind ProviderName}" 
           CloningLocation="{x:Bind CloningLocation}" 
           OwningAccount="{x:Bind OwningAccount}" 
           RepositoryToClone="{x:Bind RepositoryToClone}"
           CloneLocationAlias="{x:Bind CloneLocationAlias}"
           CloneToDevDrive="{x:Bind CloneToDevDrive}"/>
     </Button.DataContext>
     <Button.Content>
          <SymbolIcon Symbol="Edit"/>
    </Button.Content>
</Button>

The above solution isn't terrible. But, might not be tried if the person is not versed in XAML.

[michael-hawker]

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.

[jhert0]

Something things that would be nice for our project if possible:

1. Row styling
2. Aggregate row at the bottom for example averaging or summing all the data in a specific column (maybe this could be done with the ListView footer and a special control for doing these aggregates?)
3. Sorting (I know you mentioned sorting the underlying list, but it would be nice to have it built in)

[michael-hawker]

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.

[jhert0]

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

[AndrewKeepCoding]

What about row/column data direction? The DataGrid data direction goes in the row direction (top to bottom) but cannot be changed to column direction (left to right).

[michael-hawker]

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.

[AndrewKeepCoding]

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.

[Sergio0694]

Just to play devil's advocate, and also because it's not entirely clear to me: why would it not be viable to instead improve DataGrid to make it usable in these scenarios as well? Eg. one of the points listed is "user might not need selection, or editing for everything or resizing for everything". Why can't those options just be opt-in instead? For instance, ListView also has a bunch of features (item click, item selection, headers, footers, grouping, etc.) which are completely optional and opt-in. My worry is that having two completely different controls that ultimately do the same thing would make it much harder to migrate. Essentially, you can spend a lot of time building your UI using this control, then realize that maybe you also need eg. selection after all, and now you've fallen off a cliff and you're screwed. That is, either rebuild it from scratch using the "full" control, or live without that feature. Does that make sense?

[batzen]

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.

[michael-hawker]

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.

[dhoehna]

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.

[michael-hawker]

Can't remember where the TreeView/TreeGrid discussion came up (besides my other comment here); maybe it was on Discord?

Anyway, had to file microsoft/microsoft-ui-xaml#8451 as TreeView doesn't expose Header/Footer, so made a light-weight wrapper for a HeaderedTreeView (like we did for HeaderedItemsControl). And then used that to test out how the existing implementation works:

Surprisingly, did kind of what I expected, but seems promising. Think would want to have the tree part be buffered by the first column as in the example image/proposal in the WinUI repo for a 'TreeList' here: microsoft/microsoft-ui-xaml#260

That would make it easier to manager the indentation level in one spot. First step is probably understanding the size of the contents of the rows to size the columns though, haven't done that coordination in the prototype yet. Then this would need an extra bit for the TreeView around the padding on the left-side in relation to the rest of the panel/column sizes, which kind of needs to be adjusted between the ListView/ItemsControl containers anyway...

All that said, seems like an interesting scenario to keep around to tinker with as things progress and see if it's possible without much extra work, as this would be a really interesting addendum to this methodology that I didn't originally think of (but should of)!

[michael-hawker]

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.

[yaira2]

We're currently using a custom ListView + Header as a DataGrid alternative, over the years we've added a lot of functionality such as double clicking the headers to resize the column to fit the content. The logic in our app is complex and hard to scale as we add more columns, so we'll be very happy to switch to a Toolkit control.

[robloo]

Why not just do what WPF did and support GridView in a ListView.View type property. I'm pretty sure UWP can also switch a ListView to view as a table. If only a lightweight control is needed it doesn't make sense to me to write a new control and reinvent things here.

[michael-hawker]

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]

Have an initial test of resizing a column:

DataTableColumnResizeTest.mp4

Main issues to figure out are how columns should react with one another based on how they're configured. The current logic kind of uses the initial configuration to determine layout, so once that's disrupted, an altered strategy needs to be performed... This also ties into the notion of the 'Auto' sizing and figuring out how large a column wants to be based on its contents, as that's still left to investigate.

The other question is should the items below be manipulated during the column resize or only afterwards (as in the video above)? Or something in-between with some sort of debounce?

[niels9001]

@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?

[michael-hawker]

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...

[michael-hawker]

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).

[michael-hawker]

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...

[mdtauk]

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

[AndrewKeepCoding]

Now that the WinUI 3 team made it clear that they are not (or won't be?) focused on a DataGrid control, the DataTable is our best chance to have a modern DataGrid.🤩

[dongle-the-gadget]

DataGrid is from WCT though.

[michael-hawker]

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

[michael-hawker]

Huzzah! May have auto column sizing working properly now... 😋

Do need to do some more testing, and check if it doesn't break virtualization...

I have the connection more solidified between DataTable and DataRow, so need to see if there's more I can do with that for optimizations.

This was pretty straight-forward from what I had though, so still all very promising. And I have ideas for the last two issues to investigate before trying to merge the initial PR...

[yaira2]

Will this have support for reordering columns at run time?

[michael-hawker]

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.

[michael-hawker]

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.

[michael-hawker]

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.

[michael-hawker]

Thinking for column interactions:

• Tapping the column will change the sorting direction chevron (dev needs to listen and sort collection or turn on/off the chevron display)
• Double-tapping the sizer will change to auto-size the column

Not sure if sizer for column should be to the left of the content in the column at the start or right-aligned at the end of the column...

[niels9001]

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?

[kmgallahan]

WWED? (What Would Excel Do)

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

[michael-hawker]

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...

[mdtauk]

I am assuming this new control is linked to the Design Guidance in the WinUI toolkit

Will this end up using the new ItemsView control coming from the WinAppSDK File Explorer migration?

[davidegiacometti]

Hi!

I was trying to apply the DataTable to the Hosts File Editor PowerToys (currently using a ListView) and found some issues:

• If I resize the window to a small one the app crash with Microsoft.UI.Xaml.UnhandledExceptionEventArgs thrown
• Doesn't work well if you use a star sized column that isn't the last column
• Doesn't work well if an item in the DataRow isn't visible
• You have to press tab multiple times in order to focus the first item in the DataTable

Don't know if these are known issues but want to provide a feedback.

[michael-hawker]

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!

[davidegiacometti]

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.

[ghost1372]

hi @michael-hawker
i am using Datatable just like samples:

<ListView x:Name="listview"
          Grid.Row="1"
          Margin="10,0"
          x:DefaultBindMode="OneWay"
          ItemsSource="{x:Bind ViewModel.ChaptersACV}"
          SelectedIndex="{x:Bind ViewModel.ListViewSelectedIndex, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}"
          SelectedItem="{x:Bind ViewModel.ListViewSelectedItem, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}">
    <ListView.Header>
        <Border Padding="8,4,0,4"
                Background="{ThemeResource SolidBackgroundFillColorTertiaryBrush}"
                CornerRadius="4">
            <i:Interaction.Behaviors>
                <behaviors:StickyHeaderBehavior />
            </i:Interaction.Behaviors>
            <community:DataTable ColumnSpacing="16">
                <community:DataColumn Content="Id" />
                <community:DataColumn CanResize="True"
                                      Content="Name" />
                <community:DataColumn CanResize="True">
                    <TextBlock FontWeight="SemiBold"
                               Text="Description" />
                </community:DataColumn>
                <community:DataColumn Content="Quantity" />
            </community:DataTable>
        </Border>
    </ListView.Header>
    <ListView.ItemTemplate>
        <DataTemplate x:DataType="tables:ChapterProperty">
            <!--  We set HorizontalAlignment to Left here as we're not stretching our content with a star column  -->
            <community:DataRow HorizontalAlignment="Left">
                <TextBlock VerticalAlignment="Center"
                           Text="{x:Bind Id}" />
                <TextBlock VerticalAlignment="Center"
                           Text="{x:Bind Name}" />
                <TextBlock VerticalAlignment="Center"
                           Text="{x:Bind Name}" />
                <TextBlock VerticalAlignment="Center"
                           Text="{x:Bind Name}" />
            </community:DataRow>
        </DataTemplate>
    </ListView.ItemTemplate>
    <ListView.ItemContainerStyle>
        <Style BasedOn="{StaticResource DefaultListViewItemStyle}"
               TargetType="ListViewItem">
            <Setter Property="HorizontalContentAlignment" Value="Left" />
        </Style>
    </ListView.ItemContainerStyle>
</ListView>

but i am getting an exception:
Exception thrown: 'System.Runtime.InteropServices.COMException' in WinRT.Runtime.dll

[ghost1372]

oh, adding a width property fixed issue

[zsolt3991]

Attempting to test this out for replacement of DataGrid where no editing was necessary.

Came to the conclusion that for most functionality this component is a great fit. Impementing a sorting mechanism is possible with the only drawback of no built in sort indicators.

However I can see a shortcoming in the layout responsiveness, the "Cell" contents do not seem to apply Wrap or Ellipsis even if explicitly set on the TextBlock element. This shows up on resizing or even when the layout does not fit the text when initially filling the Item Collection.

Quick check in the Visual Tree, and it seems like the TextBlock instances in the list elements do not get a width set from the layout, instead they just overlap

[michael-hawker]

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.

[LeonSpors]

@michael-hawker

I'm having an issue where my TextBlock is not trimming at all when using the DataTable. Is this a known bug? If so, do you have an ETA for the fix?

[mavaa]

Not sure if this is the correct place to ask this, but am I right to assume that the DataGrid control won't be added to the 8.x and future versions of the Community Toolkit at all? And if/when the new DataTable control is added, will it be possible/easy for existing DataGrid users to switch? Probably not easy questions to answer, but we are using the DataGrid today, and are looking into how/if/when we will have to do a migration job. From browsing quickly through the discussion it seems like we might have to re-implement some features ourselves, but that won't be a showstopper if the controller as a whole is improved.

Also, is there a status/plan for what happens to this DataTable in the near/far future?

[michael-hawker]

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)

[michael-hawker]

Someone was looking at trying to do custom/dynamic column/data lengths for arbitrary dynamic tables (e.g. fetched from a database). So, still read-only display, but unknown composition at compile time.

Seems the current code base makes this a bit tricky on a couple of fronts to support, was hoping that nesting controls could help with this sort of pattern:

    <!-- Parent Table Holder of our Row Items-->
    <ListView ItemsSource="{x:Bind DataItems}">
        <ListView.Header>
            <!-- Set Header to another one for our dynamic columns -->
            <ItemsControl ItemsSource="{x:Bind ColumnInfo}">
                <ItemsControl.ItemsPanel>
                    <ItemsPanelTemplate>
                        <!-- Use DataTable here as panel for our header -->
                        <controls:DataTable x:Name="TableHeader"
                                            Margin="12,0,0,0" />
                    </ItemsPanelTemplate>
                </ItemsControl.ItemsPanel>
                <!-- Dynamically create DataColumns based on our column collection -->
                <ItemsControl.ItemTemplate>
                    <DataTemplate x:DataType="x:String">
                        <controls:DataColumn Content="{Binding}" />
                    </DataTemplate>
                </ItemsControl.ItemTemplate>
            </ItemsControl>
        </ListView.Header>
        <!-- Setup the rows themselves -->
        <ListView.ItemTemplate>
            <DataTemplate>
                <!-- Need another container for our DataRow as a panel -->
                <ItemsControl ItemsSource="{Binding}">
                    <ItemsControl.ItemsPanel>
                        <ItemsPanelTemplate>
                            <controls:DataRow TargetTable="{Binding ElementName=TableHeader}" />
                        </ItemsPanelTemplate>
                    </ItemsControl.ItemsPanel>
                    <!-- Then use standard template for how we want to display each data item -->
                    <ItemsControl.ItemTemplate>
                        <DataTemplate>
                            <TextBlock Text="{Binding}" />
                        </DataTemplate>
                    </ItemsControl.ItemTemplate>
                </ItemsControl>
            </DataTemplate>
        </ListView.ItemTemplate>
    </ListView>

Unfortunately, ran into a number of issues:

• x:Bind ran into trouble trying to figure out what to do, so had to fallback to Binding, that helped a lot more
• DataRow currently not smart enough to understand this more complex pattern, so added a shortcut for a TargetTable to test connecting it directly, this was promising.
• Also, unfortunately, the top ItemsControl for the Columns wasn't creating DataColumns and just blank ContentPresenters... not sure why. Also, the DataTable isn't smart enough to dig a layer deeper to get the info it needs here.

If we 'updated' DataTable to be instead an ItemsControl (or even ListViewBase) itself, then we could provide it directly with an ItemsSource and ItemTemplate (with DataColumn being it's ItemContainer anyway), and that may work (though have had trouble with custom container types in the past).

And being off ListViewBase, means we could potentially even try enabling drag-and-drop of the columns themselves, though cascading that down to each row to re-order its contents/layout would be interesting... though since we own the layout at that point, we just need to map the re-ordered column order to the original logical order of the collection. e.g. give each column its index, so even when re-ordered, we use that to get the index of the datarow's child to layout in the order we desire. Think that'd be the simplest, as just part of layout and doesn't actually need to mess with the visual tree.

So, in the end I think we'd end up with something like:

    <!-- Parent Table Holder of our Row Items-->
    <ListView ItemsSource="{x:Bind DataItems}">
        <ListView.Header>
            <!-- Now header is a 'super' DataTable -->
            <DataTable ItemsSource="{x:Bind ColumnInfo}" Margin="12,0,0,0">
                <!-- Dynamically create DataColumns based on our column collection -->
                <DataTable.ItemTemplate>
                    <DataTemplate x:DataType="x:String">
                        <controls:DataColumn Content="{Binding}" />
                    </DataTemplate>
                </DataTable.ItemTemplate>
            </DataTable>
        </ListView.Header>
        <!-- Setup the rows themselves -->
        <ListView.ItemTemplate>
            <DataTemplate>
                <!-- Need another container for our DataRow as a panel -->
                <ItemsControl ItemsSource="{Binding}">
                    <ItemsControl.ItemsPanel>
                        <ItemsPanelTemplate>
                            <!-- Only note here is that DataRow may find its parent ItemsControl first, so we may need a 'skip' flag or the direct link option with an ElementName binding (as x:Bind won't work for that either)... -->
                            <controls:DataRow/>
                        </ItemsPanelTemplate>
                    </ItemsControl.ItemsPanel>
                    <!-- Then use standard template for how we want to display each data item -->
                    <ItemsControl.ItemTemplate>
                        <DataTemplate>
                            <TextBlock Text="{Binding}" />
                        </DataTemplate>
                    </ItemsControl.ItemTemplate>
                </ItemsControl>
            </DataTemplate>
        </ListView.ItemTemplate>
    </ListView>

[michael-hawker]

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

[Natriss]

I wish I could help ya in this ;n;

[632575987]

I can't use the right-click to copy and paste the Datagrid cell content in uwp, the right-click menu will appear instantly and then disappear.

[ShortDevelopment]

Issue

Resizing the DataTable using a GridSplitter might throw an ArgumentOutOfRangeException:

Non-negative number required. width

at

Labs-Windows/components/DataTable/src/DataTable/DataTable.cs

Line 96 in ecf8343

column.Measure(new Size(availableSize.Width - fixedWidth - autoSized, availableSize.Height));

Package

<PackageReference Include="CommunityToolkit.Labs.WinUI.Controls.DataTable" Version="0.1.240213-build.1640" />

References

#418 (comment)

[HotCakeX]

I'm getting the same error. I removed the CanResize="True" property from the columns but still crashes for me.

[xperiandri]

It would be extremely nice to have a TreeTable control too. Where a line can have expandable subnodes.
I miss both DataTable and TreeTable in my Uno LOB app

[larcai]

There seems to me no movement on the DataTable...
What is happening with it? Is someone porting the old DataGrid to the new Community toolkit?