[develop] Fix: Direct sample logic, property usage, and code-path mistakes

[qiutongMS]

Summary

• fix direct sample logic, property usage, and code-path mistakes across 37 documentation pages in the develop docset
• validate the updated Learn links for the changed API and guidance references
• note that the Combo box and list box page already contained the expected double.TryParse fix on the base docs branch, so it required no source change

[qiutongMS]

Summary

I found a few blocking documentation issues in the latest PR state. Most edits look good, but the updated copilot-key-state.md and change-tracking-filesystem.md pages still contain technical mistakes or contradictions that should be fixed before merge.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/develop/windows-integration/copilot-key-state.md	Section "Add a property to track the Microsoft Copilot key pressed state" and later MainWindow(string state) sample	Both constructor samples assign _state = state after InitializeComponent() instead of setting State/calling SetState(state). With x:Bind State, Mode=OneWay, the initial state won't update in the UI as described.	must-fix
2	hub/apps/develop/windows-integration/copilot-key-state.md	Section "Register the window for Microsoft Copilot fastpath invocation"	The prose tells readers to retrieve an HWND with GetWindowHandle, but the sample then calls SHGetPropertyStoreForWindow((HWND)this.AppWindow.Id.Value, ...) and SetWindowSubclass((HWND)appWindow.Id.Value, ...). Those Win32 APIs require an actual HWND; the sample should use the retrieved window handle (hWndMain) or an explicit WindowId→HWND conversion helper.	must-fix
3	hub/apps/develop/files/change-tracking-filesystem.md	Section "Wait for changes"	The text refers to StorageLibraryChangedTrigger, but the linked API/type is StorageLibraryContentChangedTrigger (and StorageLibraryChangeTrackerTrigger is a different type). As written, the page names a non-existent API.	must-fix

Suggestions

#	File	Line/Section	Suggestion	Severity
1	hub/apps/develop/windows-integration/copilot-key-state.md	Section "Add a property to track the Microsoft Copilot key pressed state"	The prose says to add a TextBox, but the XAML sample uses a TextBlock. Align the wording with the sample to avoid reader confusion.	suggestion

[qiutongMS]

Summary

I found one blocking issue in the updated docs. Most changes look correct, but one modified page still contains a contradictory C++/WinRT automation-peer example that would mislead readers.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/design/accessibility/custom-automation-peers.md	Section "Initialization of a custom peer class"	The C++/WinRT NumericUpDownAutomationPeer.idl snippet still declares runtimeclass NumericUpDownAutomationPeer : Microsoft.UI.Xaml.Automation.Peers.AutomationPeer, but the page explicitly says a RangeBase-derived control should use RangeBaseAutomationPeer. Leaving the snippet as-is contradicts the surrounding guidance and shows the wrong base type to readers.	must-fix

[qiutongMS]

Review summary: I found two must-fix issues in the reviewed file subset.

1. hub/apps/windows-app-sdk/applifecycle/focus-session.md — In the "Continuously monitor focus state" C++/WinRT sample, the code uses MainWindow::OnNavigatedTo(...) even though OnNavigatedTo is a Page lifecycle method, not a Window one. As written, the MainWindow sample is not valid WinUI 3 code.

2. hub/apps/windows-app-sdk/migrate-to-windows-app-sdk/guides/toast-notifications.md — In "Step 3: Handle activation" / "Migrated App.xaml.cs", the Windows App SDK activation flow is still wrong. The page tells readers to branch on ExtendedActivationKind.AppNotification in OnLaunched, but current guidance says cold-start notification activation comes through NotificationInvoked and the activation kind is Launch, not AppNotification. As written, the sample can incorrectly show UI for background actions.

[qiutongMS]

Summary

I found 3 blocking issues in the reviewed file subset. Most edits are correct, but two changed pages still contain technical errors that would mislead or block readers.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/develop/data/store-and-retrieve-app-data.md	Section "Create and read temporary files"	The C# sample uses CreateCollisionOption.ReplaceExisting, but the enum is CreationCollisionOption. Readers copying this snippet will hit a compile error.	must-fix
2	hub/apps/develop/data/store-and-retrieve-app-data.md	Section "Organize app data with containers"	The prose says containers can be added to the "temporary app data store", but ApplicationDataContainer only applies to settings containers such as LocalSettings/RoamingSettings; the temporary store exposes TemporaryFolder and has no settings container. This contradicts the platform API model.	must-fix
3	hub/apps/develop/dispatcherqueue.md	Section "Run-down" (RunCustomMessageLoop sample)	The Win32 message-loop sample calls TranslateMesasge(&msg);. The API name is TranslateMessage, so the sample as written will not compile.	must-fix

[qiutongMS]

Review Result: CHANGES_REQUESTED

Summary

I found 3 must-fix issues in the reviewed subset. Most edits are good, but a few changed pages still contain WinUI/UWP inconsistencies or incorrect sample code.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/develop/ui/controls/controls-and-events-intro.md	C++/WinRT event handler sample (lines 119, 123, 125)	The page now points readers to Microsoft.UI.Xaml.Controls, but the C++ sample still uses winrt::Windows::UI::Xaml::* types for RoutedEventArgs and Controls::Button. In a WinUI 3 page this is inconsistent and gives readers the wrong namespaces.	must-fix
2	hub/apps/develop/ui/controls/custom-transport-controls.md	Important APIs / multiple sections (lines 18, 27, 103, 125, 270)	This page now mixes a WinUI 3 MediaTransportControls link with multiple remaining UWP Windows.UI.Xaml API links and UAP-specific guidance. The result is framework-inconsistent guidance inside one page.	must-fix
3	hub/apps/develop/ui/sound.md	Control Level State sample (line 73)	The prose and XAML sample use ElementSoundMode, but the C# sample sets ButtonName.ElementSoundState. That property name does not match the documented property and will mislead readers copying the snippet.	must-fix

[qiutongMS]

Review Result: CHANGES_REQUESTED

Summary

I reviewed the latest state of PR #18 only against the requested 20-file subset. I found two must-fix issues and a couple of non-blocking suggestions.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/develop/feeds/implement-feed-provider-win32.md	OnFeedProviderEnabled/Disabled and related C++ snippets (for example lines 141, 159, 174, 185, 200)	The page now labels the snippets as C++/FeedProvider.cpp, but multiple code blocks still start with // FeedProvider.cs. That is a direct contradiction in the updated walkthrough and will mislead readers about which source file they should edit.	must-fix
2	hub/apps/develop/files/change-tracking-filesystem.md	GetChanges() sample, Putting it together section (lines 155-162)	The sample handles folders with HandleFileChange(change) and files with HandleFolderChange(change). Those handlers are swapped, so the resulting example is logically incorrect.	must-fix

Suggestions

#	File	Line/Section	Suggestion	Severity
1	hub/apps/develop/files/pickers-save-file.md	Step 2, PickSaveFileAsync description (around line 125)	Rename FilePickResult to PickFileResult so the prose matches the actual API type name used by the linked reference page.	suggestion
2	hub/apps/develop/launch/launch-default-apps-settings.md	Query string parameter table (around lines 26-30)	The markdown table separator row has three columns while the header has two. Consider fixing the table syntax so it renders predictably.	suggestion

[qiutongMS]

Review Result: CHANGES_REQUESTED

Summary

I found several blocking documentation issues in the latest PR state. A few changed pages still contain compile-breaking sample errors or contradictory guidance, so this PR should not be merged yet.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/develop/data/store-and-retrieve-app-data.md	Section "Create and read temporary files"	The sample uses CreateCollisionOption.ReplaceExisting; the correct enum is CreationCollisionOption.ReplaceExisting.	must-fix
2	hub/apps/develop/data/store-and-retrieve-app-data.md	Section "Organize app data with containers"	The prose says containers can be added to the temporary app data store, but temporary app data exposes TemporaryFolder rather than settings containers.	must-fix
3	hub/apps/develop/dispatcherqueue.md	Section "Run-down"	The sample calls TranslateMesasge(&msg);; the Win32 API is TranslateMessage.	must-fix
4	hub/apps/develop/feeds/implement-feed-provider-win32.md	Sections "OnFeedProviderEnabled" / related C++ snippets	Several C++ snippets are still labeled // FeedProvider.cs, which contradicts the C++/WinRT walkthrough.	must-fix
5	hub/apps/develop/files/change-tracking-filesystem.md	Section "Putting it together"	The sample routes folder changes to HandleFileChange(change) and file changes to HandleFolderChange(change); those handlers are swapped.	must-fix
6	hub/apps/windows-app-sdk/applifecycle/focus-session.md	Section "Continuously monitor focus state" (C++/WinRT sample)	The sample uses MainWindow::OnNavigatedTo(...), which is a Page lifecycle method, not a Window method.	must-fix
7	hub/apps/windows-app-sdk/migrate-to-windows-app-sdk/guides/toast-notifications.md	Step 3: Handle activation	The prose says ApplicationManager.NotificationInvoked, but the page otherwise uses AppNotificationManager.NotificationInvoked.	must-fix

[qiutongMS]

Summary

I found two must-fix issues in the current PR state. Most edits look good, but these two pages still contain reader-blocking technical problems.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/develop/windows-integration/recall/recall-web-browsers.md	Intro + sample code	The page now tells readers to use IS_PRIVATE, but the sample enum still defines value 0x1f with a password-oriented comment. Microsoft Learn's current Recall guidance and the InputScope enum map 0x1f to IS_PASSWORD, while IS_PRIVATE is value 61. As written, the prose and code disagree and at least one is wrong.	must-fix
2	hub/apps/develop/windows-integration/copilot-key-state.md	Section "Microsoft Copilot hardware key app extension"	The manifest snippet is not copy/pasteable: myapp-copilothotkey:?//state=Up is a malformed URI, and </ uap3:AppExtension> has an invalid closing tag. This leaves the page with broken XML in a core setup step.	must-fix

[qiutongMS]

Review Result: CHANGES_REQUESTED

Summary

Most of the fixes in this PR look correct, but one modified page still has a technical issue that should be fixed before merge.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/develop/ui/sound.md	Section "Control Level State"	The updated prose correctly says the control uses ElementSoundMode, but the code sample still uses ButtonName.ElementSoundState = ElementSoundMode.Off;. ElementSoundState is not the documented control property; the property is ElementSoundMode. This leaves the page internally inconsistent and gives readers non-working sample code.	must-fix

[qiutongMS]

Review Result: APPROVED

Summary

I reviewed the PR diff and the full modified pages. The fixes align with the affected APIs, links I spot-checked resolve, and I did not find any blocking technical or editorial issues in the updated content.