DataGridTemplateColumn should have independent edit events

[michael-hawker]

Came from discussion here: #4206 (review)

Describe the bug

DataGridTemplateColumn is hard to customize as it expects to take DataTemplates nicely from XAML, but then has overrides for a subclass on its methods like PrepareCellForEdit and CancelCellEdit vs. having event based properties. To customize this behavior you have to hook into PreparingCellForEdit event on the DataGrid and then look for the specific column you want vs. having registered the event on the column directly for the one case you may want to override.

Expected behavior

Able to modify the behavior of a base DataGridTemplateColumn without sub-classing.

Additional context

I propose we add two new events to the DataGridTemplateColumn class (or maybe even the base DataGridColumn: PrepareCellForEdit and CancelCellEdit which could be called after the subclass has been called in the Internal methods here:

WindowsCommunityToolkit/Microsoft.Toolkit.Uwp.UI.Controls.DataGrid/DataGrid/DataGridColumn.cs

Lines 987 to 990 in 0ee2c84

	internal void CancelCellEditInternal(FrameworkElement editingElement, object uneditedValue)
	{
	CancelCellEdit(editingElement, uneditedValue);
	}

WindowsCommunityToolkit/Microsoft.Toolkit.Uwp.UI.Controls.DataGrid/DataGrid/DataGridColumn.cs

Lines 1258 to 1261 in 0ee2c84

	internal object PrepareCellForEditInternal(FrameworkElement editingElement, RoutedEventArgs editingEventArgs)
	{
	return PrepareCellForEdit(editingElement, editingEventArgs);
	}

The sender would be the column and we could construct event args which contain the returned object from the subclass, the editing element, and the other editing args?

This would make it easier to customize a specific column (and/or also have a general override behavior for every column) without having to continually check for specific columns in the main DataGrid PreparingCellForEdit event?

Currently what we have to do:

dataGrid.PreparingCellForEdit += DataGrid_PreparingCellForEdit;

private void DataGrid_PreparingCellForEdit(object sender, DataGridPreparingCellForEditEventArgs e)
{
    if (e.Column is DataGridTemplateColumn column && (string)column?.Tag == "First_ascent" &&
        e.EditingElement is CalendarDatePicker calendar)
    {
        calendar.IsCalendarOpen = true;
    }
}

Proposal (add event to Column directly from XAML):

private void DataGridTemplateColumn_PreparingCellForEdit(DataGridTemplateColumn sender, DataGridColumnPreparingCellForEditEventArgs e)
{
    if (e.EditingElement is CalendarDatePicker calendar)
    {
        calendar.IsCalendarOpen = true;
    }
}

Thoughts, concerns @RBrid?

[ghost]

Hello michael-hawker, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[ghost]

Hello, 'michael-hawker! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[lukeblevins]

@michael-hawker This sounds good to me, considering a user's natural tendency against subclassing DataGridTemplateColumn when:

• Other DataGridColumn derivatives likely won't require it for their standard use cases
• The DataGridTemplateColumn happily exposes a mechanism to take DataTemplates from markup

wrt. one of your proposed events on DataGridColumn, would it produce a measurable difference from the PreparingCellForEdit-which returns the Column/Row-and exists on the DataGrid control itself?

[michael-hawker]

@duke7553 yeah, I started writing this and then realized the parent DataGrid had a catch-all event. I just like the idea as a developer that I can just add an event to the one templated column I have without having to have some way of checking which column is the column being edited as in the first example I showed at the end of the proposal.

Overall a developer could use either approach still. This is really just a proposed alternative to make it a bit simpler/discoverable.

I could also see a case where if you have some special logic you want to do for every column for some undo mechanism maybe you could have that in the DataGrid event, but then still have the specific logic to a particular column in its own event to like pop-open the Calendar picker on edit.

I updated the sample I proposed for your existing PR to use the DataGrid event, and this particular proposal we can look at later for another milestone in the future (or discuss more with the WinUI team whenever they get to looking at the DataGrid re-implementation in WinUI).