[develop] Fix: UWP→WinAppSDK migration — camera & integration

[qiutongMS]

Summary

• replace 21 UWP XAML API links in the manual camera controls article with WinAppSDK API references
• replace 4 UWP XAML API links in the MediaFrameReader article with WinAppSDK API references
• update the packaged share target article to link AppInstance.GetActivatedEventArgs to the WinAppSDK AppLifecycle reference

Completeness Check

• Findings in fix report: 26
• Files modified: 3
• Findings addressed: 26

Skipped Findings

• None.

Validation

• git diff --check
• verified 15 unique replacement links return HTTP 200

Notes

• The requested base branch main does not exist in qiutongMS/windows-dev-docs; this PR targets the repository default branch docs.

[qiutongMS]

Summary

I found 2 must-fix issues in the updated links. Most replacements resolve correctly, but two changed hunks now point readers to the wrong API pages.

Must-Fix Issues

1. hub/apps/develop/windows-integration/integrate-sharesheet-packaged.md — In Fetch Share Event arguments, the new link for AppInstance.GetActivatedEventArgs points to Microsoft.Windows.AppLifecycle.AppInstance.GetActivatedEventArgs. That API's remarks say unsupported activation kinds return null, and ShareTarget isn't one of the supported Windows App SDK activation kinds. This article's example immediately uses ActivationKind.ShareTarget, so the link is misleading here; it should point back to the packaged-app activation API used for share-target activation.
2. hub/apps/develop/camera/process-media-frames-with-mediaframereader.md — In Use MediaSource to display frames in a MediaPlayerElement, the prose says to call SetMediaPlayer, but the new link points to the MediaPlayerElement.MediaPlayer property page instead of the SetMediaPlayer method page. Please retarget that link to the method documentation.

[qiutongMS]

Summary: The link updates themselves look good, but one modified page still contains UWP-only threading guidance that is incorrect for a Windows App SDK / WinUI 3 article.

Must-fix:

1. hub/apps/develop/camera/process-media-frames-with-mediaframereader.md — In the "Handle the frame arrived event" section, the page still instructs readers to use CoreDispatcher and RunAsync to marshal back to the UI thread. In Windows App SDK / WinUI 3, CoreDispatcher migrates to DispatcherQueue, and the guidance should point readers to DispatcherQueue / TryEnqueue (or the WinUI 3 equivalent used by the sample) instead. As written, a newcomer following this page can be sent to the wrong threading model.

[qiutongMS]

Summary: The new WinAppSDK API links you added resolve correctly, but I found a few reader-facing API-reference mismatches that still need to be fixed before merge.

Must-fix issues:

1. hub/apps/develop/camera/capture-device-controls-for-photo-and-video-capture.md — Section Exposure compensation: the Supported link still points to /windows/uwp/audio-video-camera/supported-codecs instead of the ExposureCompensationControl.Supported API reference.
2. hub/apps/develop/camera/capture-device-controls-for-photo-and-video-capture.md — Sections Flash / Focus: the Supported links are cross-wired (FlashControl text links to FocusControl.Supported, and the focus sections link to FlashControl.Supported).
3. hub/apps/develop/camera/capture-device-controls-for-photo-and-video-capture.md — Section White balance: the SetValueAsync sentence links to ExposureControl.SetValueAsync instead of WhiteBalanceControl.SetValueAsync.

Suggestions:

• hub/apps/develop/windows-integration/integrate-sharesheet-packaged.md — Consider linking AppInstance.GetActivatedEventArgs to the WinAppSDK Microsoft.Windows.AppLifecycle.AppInstance.GetActivatedEventArgs reference instead of leaving it as inline code.
• hub/apps/develop/camera/process-media-frames-with-mediaframereader.md — Consider updating the remaining Image API reference in The FrameRenderer helper class to the WinAppSDK Microsoft.UI.Xaml.Controls.Image page for consistency.

[qiutongMS]

Summary:
I reviewed the latest diff and the full modified pages. The Windows App SDK link updates are technically sound, the changed links resolve, and I did not find any must-fix issues that should block merge.

Suggestions:

• hub/apps/develop/windows-integration/integrate-sharesheet-packaged.md: Consider linking AppInstance.GetActivatedEventArgs to the Windows App SDK API page (/windows/windows-app-sdk/api/winrt/microsoft.windows.applifecycle.appinstance.getactivatedeventargs) instead of leaving it as code formatting only.