Saharsh Ananta Jaiswal
e43de2ad2c
Builds on #12120. TableView's TiP blames the app only when its own code decided the outcome, each key operation has its own TiP test and measure, and telemetry records one event per table load. ## TiP tests | Test | Measure | Fails with | |---|---|---| | Initialize | 64477764 | `template_setup_failed`, `source_attach_failed` | | Sort | 64745033 | `sort_failed` | | Edit begin | 64745034 | `edit_begin_failed` | | Edit commit | 64745035 | `edit_commit_failed` | | Filter | 64745036 | `filter_failed` | | Expand or collapse one group | 64745037 | `group_expansion_failed` | | Expand or collapse one tree node | 64745038 | `hierarchy_expansion_failed` | - A test fails, with the HRESULT, only when TableView's own code throws. App code's exceptions are tagged where TableView calls it, so the test closes Ignored (`application_fault`) only when one of them decided the outcome. - Column code: the editing hooks are TableView's for every column, except where they realize or focus a `CellEditingTemplate`'s content. That content, and the overrides of a column class the app derived, are the app's. - Initialize runs from the template applied with a source attached until the first row or group header is laid out. Unloaded before that with rows and a body viewport, it closes Ignored as `unloaded_before_render`; otherwise as `unloaded`. - The metrics bucket is the flow direction and whether the source has at least 1,000 rows before the filter. The metrics carry both row counts. - No test runs for selection, a source swap after Initialize, a cancelled edit, group configuration, a subtree expansion or an expansion request that changes nothing. A failure in any of them still writes `TableView_Error`. - A process exit while a test runs is recorded by TiP as that test's failure, and so is a crash or hang on Windows builds whose Error Reporting recovers TiP results. - 64477774, the old combined operation test, is retired after this merges. ## Telemetry - `TableView_Instance` (one per load) replaces `TableView_SessionSummary`: enabled and used features, source-row, data-row and realized-row buckets, column and source kinds, RTL, and an incomplete template. - An app filter predicate, sort or group key selector or custom comparer that throws is still contained, and now writes one recoverable `TableView_Error` per operation with the first HRESULT and a `FaultCount`, also when the operation then fails. A verb an app delegate starts inside another counts only its own. - Scrolling is not measured in the field; scroll performance is left to a lab benchmark. ## Validation - 28 operation, 15 Initialize and 20 `TableView_Instance` cases, checked from captured ETW events of the final build. The 7 operation and Initialize cases whose behavior changes also ran on `f6c060a` and differ there; the other 22 operation cases match it. - 175 earlier cases rerun against `42b575b`: 174 identical; the other now also reports a group key that threw inside a filter that then threw an app data fault, as intended. - A local fault-injection build forces 19 failure paths, including built-in and app-derived column code, TableView's own code around a `CellEditingTemplate` editor, failures after contained app delegates, an unload before the first row's layout pass, and a swallowed app exception. TableView's own failures fail their test with its reason and the HRESULT; an app-tagged one closes Ignored. - UI Automation walkthrough of the final build (sort, edit, filter, group, tree node, selection): 13 successes, each under its own measure, none for selection, and no `TableView_Error`. - MSBuild: an internal pipeline build fails when the TiP package or its config is missing; the real package, the opt-out, local builds and external pipelines pass. A build with the public stub compiles. ## Notes - Versions start at 1 (`SchemaVersion`, `InstanceVersion`, both TiP data versions), since nothing has shipped. - Internal pipeline builds (`IsInternalWinUIBuild` and `TF_BUILD`) fail when Tabular falls back to the public TiP stub; `UseTestInProductionStub=true` chooses it on purpose. - The dev spec's "Telemetry and TiP" section documents every event, test, field and known gap. - Left out of the telemetry plan: a resource-load outcome (a missing `TabularControlsResources` fails at XAML parse) and separate "reached past the box" bits (`ColumnKinds` covers them). - Commits: `TableView_Instance` (`1737209`), Initialize (`6687f88`), per-operation tests (`1f82669`), review fixes (`927f474`), merge with main after #12307 (`42b575b`, conflicts in `BeginEdit` and the sort apply path), Copilot review fixes (`1f66475`). Review with whitespace hidden.
WinUI
About WinUI · Documentation · Release notes
WinUI is a user interface layer that contains modern controls and styles for building Windows apps. The current generation is WinUI 3, which ships as part of the Windows App SDK.
- Modern UI: WinUI embodies Fluent Design to enable intuitive, accessible, and powerful experiences and the latest user interface patterns.
- Developers in control: Use .NET with C# or C++ to write apps that run great on x86, x64 and ARM.
- Optimized for modern experiences & hardware: Create performant experiences with WinUI that are optimized for modern hardware.
- Part of the Windows App SDK: The Windows App SDK is a set of libraries, frameworks, components, and tools that you can use in your apps to access powerful Windows platform functionality from all kinds of apps on many versions of Windows. The Windows App SDK combines the powers of Win32 native applications alongside modern API usage techniques, so your apps light up everywhere your users are.
- Powers key experiences in Windows: Windows experiences and apps are built with WinUI. Its rich control set and styles make it easy to develop high-quality experiences used by millions every day.
📋 Getting started with WinUI
For WinUI, your app's users must be on Windows 10 1809 - Build 17763 or newer (including Windows Insider Previews).
The full documentation of WinUI can be found on Microsoft Learn:
- Get started with WinUI
- Build your first WinUI app
- Migrate from UWP to the Windows App SDK
- Windows Runtime APIs not supported in desktop apps
- WinUI & Windows App SDK samples
🖼️ WinUI 3 Gallery
Make sure to also check out the WinUI 3 Gallery, our interactive sample experience showing everything you can do with WinUI.
📺 WinUI Community Call
The WinUI Community Call is your opportunity to learn about WinUI and to engage with the WinUI team and community. Join us online on YouTube at the Windows Developer channel.
📢 Contributing to WinUI
The WinUI team welcomes your feedback! To understand how we handle incoming feature requests and bugs, please see our contribution handling guidelines.
For information on how to contribute, please see Contributing to WinUI.
Warning
We're not yet ready to accept code contributions, but we are working towards that goal. It is now possible to build the WinUI product binaries, with work in progress to share test code and enabling locally running tests. To get started building WinUI from source and see more details on current limitations, see Getting started with building WinUI. See the WinUI OSS Update post to check the latest status.
For the latest code and updates, use the
mainbranch.
🛣️ Roadmap
For info on the WinUI release schedule and high level plans please see the WinUI roadmap.
🔧 WinUI for UWP
WinUI for UWP (WinUI 2) is a library of controls that provides Microsoft UI controls and features for UWP apps. Learn more about WinUI for UWP here or download the source code here.
You can get the WinUI 2 Gallery on the Microsoft Store and see the source code here.
Data/Telemetry
This project collects usage data and sends it to Microsoft to help improve our products and services. Note, however, that no data collection is performed when using your private builds.
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct.
For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.