From 5dd215d1fbe1390f3c5a1761876b10b2de922c77 Mon Sep 17 00:00:00 2001 From: Jon Wiswall Date: Tue, 4 Feb 2025 22:06:45 -0800 Subject: [PATCH 1/2] AppDataPaths::LocalAppData throws, not Get* This code when run in an unpackaged app (say, a test environment) succeeds and returns an AppDataPaths instance, but the app-specific properties fail. ```c++ std::filesystem::path GetApplicationData(winrt::Windows::System::User user) { auto paths = user ? winrt::Windows::Storage::AppDataPaths::GetForUser(user) : winrt::Windows::Storage::AppDataPaths::GetDefault(); return std::wstring_view{ paths.LocalAppData().c_str() }; } ``` Updated the remarks to match the behavior. --- windows.storage/appdatapaths.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows.storage/appdatapaths.md b/windows.storage/appdatapaths.md index bb62f4f731..5b4f091508 100644 --- a/windows.storage/appdatapaths.md +++ b/windows.storage/appdatapaths.md @@ -15,7 +15,7 @@ AppDataPaths returns paths to commonly used application folders based on the [KN ## -remarks This class returns paths that are always isolated per the caller’s context. For example, this will match expectations of cross-platform app developers who might have used “private” versions of documents in the past. There is no legacy COM interop interface for this type. -Requesting folder locations from an app that doesn’t have a package identity will fail (for example, [GetDefault](appdatapaths_getdefault_846721868.md) and [GetForUser](appdatapaths_getforuser_2058550280.md) will both return null). This ensures there are no migration issues if an app depends on the per-app locations being shared (Win32), or if the app paths change when using the Desktop Bridge. +Requesting app-specific folder locations from a an app without package identity (for example, [LocalAppData](appdatapaths_localappdata.md)) will fail. This ensures there are no migration issues if an app depends on the per-app locations being shared (Win32), or if the app paths change when using the Desktop Bridge. ## -see-also From 089fb3246356155d01fbf6a8fd62ad3d5fefc4b1 Mon Sep 17 00:00:00 2001 From: Jon Wiswall Date: Tue, 4 Feb 2025 22:07:59 -0800 Subject: [PATCH 2/2] Update appdatapaths.md Oopsie --- windows.storage/appdatapaths.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows.storage/appdatapaths.md b/windows.storage/appdatapaths.md index 5b4f091508..625c8ca3d1 100644 --- a/windows.storage/appdatapaths.md +++ b/windows.storage/appdatapaths.md @@ -15,7 +15,7 @@ AppDataPaths returns paths to commonly used application folders based on the [KN ## -remarks This class returns paths that are always isolated per the caller’s context. For example, this will match expectations of cross-platform app developers who might have used “private” versions of documents in the past. There is no legacy COM interop interface for this type. -Requesting app-specific folder locations from a an app without package identity (for example, [LocalAppData](appdatapaths_localappdata.md)) will fail. This ensures there are no migration issues if an app depends on the per-app locations being shared (Win32), or if the app paths change when using the Desktop Bridge. +Requesting app-specific folder locations from an app without package identity (for example, [LocalAppData](appdatapaths_localappdata.md)) will fail. This ensures there are no migration issues if an app depends on the per-app locations being shared (Win32), or if the app paths change when using the Desktop Bridge. ## -see-also