-
-
Notifications
You must be signed in to change notification settings - Fork 59
Add Row Editing Highlight and Tap-to-Edit support for Row selection Mode #342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -103,6 +103,11 @@ | |
| { | ||
| base.PrepareContainerForItemOverride(element, item); | ||
|
|
||
| if (element is TableViewRow { } recycledRow) | ||
| { | ||
| recycledRow.ApplyEditingHighlight(false); | ||
| } | ||
|
|
||
| DispatcherQueue.TryEnqueue(() => | ||
| { | ||
| if (element is TableViewRow row) | ||
|
|
@@ -111,6 +116,13 @@ | |
| row.ApplyCellsSelectionState(); | ||
| row.RowPresenter?.ApplyDetailsPaneState(item); | ||
|
|
||
| // Reset current cell border on all cells in recycled containers | ||
| // to clear stale "Current" visual state from previous use. | ||
| foreach (var cell in row.Cells) | ||
| { | ||
| cell.ApplyCurrentCellState(); | ||
| } | ||
|
|
||
| if (CurrentCellSlot.HasValue) | ||
| { | ||
| row.ApplyCurrentCellState(CurrentCellSlot.Value); | ||
|
|
@@ -184,7 +196,7 @@ | |
|
|
||
| do | ||
| { | ||
| newSlot = GetNextSlot(newSlot, shiftKey, e.Key is VirtualKey.Enter); | ||
| newSlot = GetNextSlot(newSlot, shiftKey, e.Key is VirtualKey.Enter || (e.Key is VirtualKey.Tab && SelectionUnit is TableViewSelectionUnit.Row)); | ||
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don’t think this change is necessary because the Tab key should always move to the next editable cell and put it in editing mode. If there’s no editable cell in the current row, it will automatically move to the next row. |
||
|
|
||
| } while (isEditing && Columns[newSlot.Column].IsReadOnly); | ||
|
|
||
|
|
@@ -597,7 +609,7 @@ | |
| } | ||
| else | ||
| { | ||
| foreach (var propertyInfo in dataType.GetProperties()) | ||
|
Check warning on line 612 in src/TableView.cs
|
||
| { | ||
| var displayAttribute = propertyInfo.GetCustomAttributes().OfType<DisplayAttribute>().FirstOrDefault(); | ||
| var autoGenerateField = displayAttribute?.GetAutoGenerateField(); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -603,6 +603,14 @@ internal void UpdateSelectCheckMarkOpacity() | |
| } | ||
| } | ||
|
|
||
| /// <summary> | ||
| /// Highlights or unhighlights the row to indicate that a cell is being edited. | ||
| /// </summary> | ||
| internal void ApplyEditingHighlight(bool isEditing) | ||
| { | ||
| RowPresenter?.ApplyEditingHighlight(isEditing); | ||
| } | ||
|
|
||
|
Comment on lines
+606
to
+613
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This code block seems a bit off. I suggest adding an accent-tinted border or rectangle in the TableViewRowPresenter above the RootPanel, and controlling its visibility from the code-behind. For that, you can use the Cell.PrepareForEdit and Cell.EndEditing methods.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed, that code was a bit off. What we were trying to do was mimic the pointer-over look by directly swapping the row's background when editing started and restoring it when done. The problem was it kept clashing with EnsureAlternateColors (we had to add a guard to stop it from overwriting the highlight), and we needed #if WINDOWS branching because Uno handles it differently. So we went with your suggestion, added a Border overlay in TableViewRowPresenter.xaml sitting above the RootPanel, hit-test invisible, collapsed by default. The code-behind just toggles its visibility. Much cleaner since the highlight is now completely separate from the row's background, no guards, no platform branching. We added a TableViewRowEditingHighlightBackground theme resource in Resources.xaml for Light, Dark and HighContrast. And the visibility is driven from PrepareForEdit/EndEditing as you suggested. |
||
| /// <summary> | ||
| /// Gets the height of the horizontal gridlines. | ||
| /// </summary> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this isn't right because the tab key should always put the next editable cell in the same row. If there is no editable cell in the same row, it will automatically jump to the next row or previous row with shift + tab.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, GetNextSlot already cycles through editable cells and wraps to the next row on its own.
What we were going for is the File Explorer–style behavior where Tab during rename jumps to the next row and starts editing it. Tab feels natural for quick back-to-back editing since it's the standard "next field" key. We tied it to SelectionUnit.Row because in Row mode the user is already working row by row, so it felt like a natural fit.
If we want to keep this separate from selection mode, we could add a TabNavigationMode property (Horizontal/Vertical) on TableView , similar to how TapToEdit works. It would just be one extra check in HandleNavigations, no changes to GetNextSlot itself. Should we go with that, or do you think it should be handled differently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get your point that in File Explorer, pressing the Tab key while editing a file name jumps to the next row. The key thing to note is that File Explorer only has one editable column and it's the Name column. So, TableView would behave exactly the same when there’s only one editable column in a row, jumping across rows with the Tab key.