Tabular: add opt-in per-cell tooltips to TableView

[Hitesh Kumar (hiteshkrmsft)]

Adds an opt-in per-cell tooltip to TableView.

Text cells render with CharacterEllipsis and no wrapping, so a value wider than its column is unreadable and an app has no way to surface the full text. CellToolTipRequested gives it one: the handler receives the row's Item and the cell's Column, and sets Content.

It is opt-in — with no handler attached the control does no per-cell work and allocates nothing — and it is resolved per cell as rows realize and recycle, so a virtualized table only pays for what is on screen.

API

[MUX_PREVIEW][webhosthidden]
runtimeclass TableViewCellToolTipRequestedEventArgs
{
    Object Item { get; };
    MU_XC_NAMESPACE.TableViewColumn Column { get; };
    Object Content { get; set; };
    String ToolTipHelpText { get; set; };
};

// on TableView
event TypedEventHandler<TableView, TableViewCellToolTipRequestedEventArgs> CellToolTipRequested;
void InvalidateCellToolTips();

table.CellToolTipRequested += (s, e) =>
{
    if (e.Item is Order order && e.Column.Header as string == "Notes")
    {
        e.Content = order.Notes;   // full text, untruncated
    }
};

Design

The control owns the ToolTip. Content is the tooltip's content, not a ToolTip to attach. ToolTipService rebinds a ToolTip's owner and container on every registration, so one instance handed back for several cells would leave them contending for a single owner slot and one set of event tokens. The control creates the object and sets PlacementMode.Mouse, since cells are arbitrarily wide and element-relative placement can land the tip far from the pointer.

Ownership is recorded, not inferred. A private attached record holds the ToolTip the control attached and the exact HelpText it published, compared against what is actually on the element. A tooltip the app replaces is detected and left alone; the control only ever touches what it put there. Recording before attaching means a failure degrades to "not ours" rather than orphaning a tooltip nothing can clear.

Recycling. A recycled row never shows or announces a previous item's tooltip, including after the last handler is removed — retraction does not depend on a handler still being attached. A row recycled out of view releases app-supplied content rather than pinning it in the repeater's pool. Control-created tooltips are neutralized in place rather than detached, so scrolling reuses the object instead of allocating a Control per cell per scroll, matching TabViewItem.

Re-entrancy. The event reaches app code from the cell realization path, so the pass snapshots its targets rather than walking the live children collection, and holds a strong reference across the raise. A rebuild triggered from a handler is recorded and replayed after the pass rather than running underneath it. InvalidateCellToolTips() is coalesced onto the dispatcher rather than raising synchronously, so it is safe to call from inside a handler.

Accessibility

The tooltip text is published as the cell's AutomationProperties.HelpText unless the cell already reports that text, so the information reaches assistive technology exactly once instead of being pointer-only or announced twice. The comparison uses the same cell-text helper TableViewCellAutomationPeer uses to compose its name, so the two cannot drift.

When Content is not a string it cannot be stringified, and the cell wrapper the tooltip attaches to is internal — an app cannot set HelpText on it. ToolTipHelpText is the supported way to supply the accessible equivalent.

The popup itself is pointer-only: cell focus in TableView is row-level, so there is no cell element for the framework's keyboard-tooltip path to fire on. The UIA pairing is what serves keyboard and screen-reader users, and that is why it is not optional.

Deferred

Column-header and group-header tooltips. PART_HeaderScroller is IsHitTestVisible="False" and hosts every header cell, and it is scrolled programmatically from the body — a header tooltip could never open, and making the band hit-testable is template work beyond this change. Grouping is not wired into TableView on main yet. Both surfaces land with the work that makes them interactive.

Notes for reviewers

Generated files. controls/dev/Generated/TableView.properties.* and controls/dev/dll-tabular/XamlMetadataProviderGenerated.h are codegen output and are regenerated here rather than hand-edited. The regeneration also picks up GroupHeaderTemplate and the group-header/group-info entries, which are already declared in the IDL but had not been regenerated into the checked-in output — that churn is not from this change. The generated header is committed rather than left to the incremental codegen target, whose Inputs/Outputs timestamp comparison can be skipped on a fresh clone.

Tooltip property teardown. The ownership property is registered lazily, outside the generated TableViewProperties, so XamlMetadataProviderGenerated.tt now emits its clear call into ClearTypeProperties() and emits its own #include. Without it a XAML re-initialization would keep handing out a registration from the torn-down core. Only controls/dev/dll-tabular is affected; the MUXC provider has its own template and does not host TableView.

Testing. There is no TableView test project in the repo yet, so this change ships without automated coverage; the behavioural contract is written down in docs/design-notes/TabularControls/TableView-functional-spec.md and the API in docs/api-specs/TableView/TableView-spec.md so tests have something to bind to. The control DLL builds clean, but the tooltip behaviour has not been exercised at runtime — worth weighting in review, particularly the recycling and UIA-pairing paths.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.