## Summary of the Pull Request
The ExprTk result was previously parsed with CurrentCulture, which means
that calculator was broken on every device which's culture info differed
from what ExprTk returns.
It would probably be better to just obtain the result as a double
directly, but that can wait.
## PR Checklist
- [x] **Closes:** #40305
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** No need
- [x] **New binaries:** None
- [x] **Documentation updated:** No need
## Detailed Description of the Pull Request / Additional comments
ExprTk, the math library that CmdPal's Calculator uses, returns the
result as a string formatted in `en-US`, therefore we need to also parse
it as `en-US`.
## Validation Steps Performed
Small and large numbers work correctly with all decimal separators
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
### Root cause:
`FileVersionInfo.GetVersionInfo(Assembly.Location)` is not compatible
with NativeAOT
### Fix:
Replaced the usage of FileVersionInfo with static reflection
`GetCustomAttribute<AssemblyFileVersionAttribute>()?.Version`. This uses
static reflection to read version metadata directly from the assembly,
which is fully supported in NativeAOT. It does not require file system
access and is trimming/AOT-safe.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:**
[#40151](https://github.com/microsoft/PowerToys/issues/40151)
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
A memory leak was identified where activating a Command Palette
extension via a hotkey would lead to a linear increase in resource
consumption and a corresponding decrease in search performance.
Each activation created a new `PageViewModel` instance for the
extension's UI. However, the `ShellViewModel` did not dispose of the
previous `PageViewModel` instance when a new one was created.
The fix is implemented in
`Microsoft.CmdPal.UI.ViewModels/ShellViewModel.cs` by ensuring that
`PageViewModel` instances are correctly disposed of when they are no
longer active.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #40199
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here
## Detailed Description of the Pull Request / Additional comments -->
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
1. Installed [Workspace Launcher for Visual Studio /
Code](https://github.com/tanchekwei/WorkspaceLauncherForVSCode)
2. Configured a global hotkey for the extension (e.g., Alt + Q).
3. Ran the following AHK script. Pressing F1 simulates pressing the
hotkey 10 times with a 200ms interval, followed by typing p to trigger a
search and observe how many times `GetItems` is invoked.
```ahk
#NoEnv
SetBatchLines, -1
; Press F1 to run the sequence
F1::
Loop, 10
{
Send, !q
Sleep, 200
}
Send, p
return
```
### Before the Fix (PowerToys v0.91.1)
- Pressing the hotkey 10 times then search will triggered `GetItems` 12
times.
- See video and log output below:
https://github.com/user-attachments/assets/3c7d59d6-2dda-4ab4-b230-2f2472c45776
```log
[2025-06-25 00:04:58.251] [VisualStudioCodePage.UpdateSearchText] Started
[2025-06-25 00:04:58.251] [VisualStudioCodePage.UpdateSearchText] SearchText: p
[2025-06-25 00:04:58.251] [WorkspaceFilter.Filter] Started
[2025-06-25 00:04:58.263] [WorkspaceFilter.Filter] Finished in 11ms
[2025-06-25 00:04:58.269] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.269] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.373] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.373] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.408] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.408] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.445] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.446] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.485] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.486] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.524] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.525] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.563] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.564] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.604] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.604] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.645] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.645] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.685] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.686] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.755] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.756] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.798] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:04:58.798] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:04:58.843] [VisualStudioCodePage.UpdateSearchText] Finished in 591ms
```
### After the Fix
- Pressing the hotkey 10 times then search will now triggers `GetItems`
only once.
- See updated video and log output:
https://github.com/user-attachments/assets/e38f3eb5-5353-44da-a9d9-ff83647eb6e9
```log
[2025-06-25 00:03:44.862] [VisualStudioCodePage.UpdateSearchText] Started
[2025-06-25 00:03:44.863] [VisualStudioCodePage.UpdateSearchText] SearchText: p
[2025-06-25 00:03:44.864] [WorkspaceFilter.Filter] Started
[2025-06-25 00:03:44.866] [WorkspaceFilter.Filter] Finished in 2ms
[2025-06-25 00:03:44.870] [VisualStudioCodePage.GetItems] Started
[2025-06-25 00:03:44.870] [VisualStudioCodePage.GetItems] Finished in 0ms
[2025-06-25 00:03:44.909] [VisualStudioCodePage.UpdateSearchText] Finished in 46ms
```
- Renaming "Kill process" to "End task" to align with Windows.
- Updating End task and Close window icons to align with End Task in
Windows.
---------
Co-authored-by: Niels Laute <niels.laute@live.nl>
Commenting out code from chat with the team for right now. we haven't
had time to fully kick the tires and want to be 100% sure the life cycle
is great for end users
---------
Co-authored-by: Gordon Lam (SH) <yeelam@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
ok... it seems didn't work since 0.91.
Maybe we forgot to send message when command has more commands?
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
When we call RaiseItemsChanged, it will trigger function GetItems. So if
you enter this function through typing query, it will trap in an inf
loop. Eventually leading to crash.
related change: https://github.com/microsoft/PowerToys/pull/40050
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39973
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Co-authored-by: Yu Leng <yuleng@microsoft.com>
## Problem
The "Reload" command in the Command Palette was only showing up when
searching with a lowercase 'r' (e.g., "reload") but not with an
uppercase 'R' (e.g., "Reload"). This was inconsistent with the
documentation which references a "Reload" command.
## Solution
Fixed the case-sensitivity issue in `FallbackReloadItem.UpdateQuery()`
by changing the string comparison from case-sensitive to
case-insensitive:
```csharp
// Before
_reloadCommand.Name = query.StartsWith('r') ? "Reload" : string.Empty;
// After
_reloadCommand.Name = query.StartsWith("r", StringComparison.OrdinalIgnoreCase) ? "Reload" : string.Empty;
```
This change makes the Reload command visible when typing either "reload"
or "Reload" in the Command Palette, improving the user experience for
extension developers.
Fixes#39769.
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: zadjii-msft <18356694+zadjii-msft@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Fixed a simple English grammar error in SamplePagesExtension in CmdPal.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR addresses an issue where ActionRuntime initialization may
repeatedly incur delays and fail during runtime usage, especially when
the OS supports the API but action creation fails.
### Fix:
Introduced ActionRuntimeManager to:
- Manage a shared static ActionRuntime instance
- Perform initialization once, at extension loading time
- Store the result (success or failure) to avoid repeated creation
attempts
Consumers now:
- ActionRuntimeManager.InstanceAsync.GetAwaiter().GetResult()
Initialization will only be attempted up to 3 times. After that, runtime
is marked as unavailable and no further attempts are made.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #40228
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
"Show Tray Icon" when you click tray icon has not sense.
If it's visible, show that has no effect,
if it's not, you can't make it visible by click it.
Remove the menu for that
This impl is just not showing the menu item, if open for the choice that
show "hide the tray icon" here
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Locally tested
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR addresses an issue where direct double output from exprtk
evaluation led to precision artifacts (e.g., 12.2 + 10 resulting in
22.199999999999999). This behavior is due to how double represents
decimal fractions in binary.
- To improve user-facing precision, the result is now:
- Converted to decimal for higher decimal accuracy.
- Rounded to fit within 15 total significant digits (integer +
fraction).
- Formatted using "G29" to eliminate unnecessary trailing zeros.
- Cleaned up to remove dangling decimal points.
This ensures more intuitive and readable output like:
- 1.9999999999 → "1.9999999999"
- 100000.9999999999 → "100001"
- 100000.999999999 → "100000.999999999"
This change improves clarity, especially for users entering expressions
expecting decimal-accurate results.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #40097
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This change addresses a significant performance regression caused by
improper handling of null-terminated strings returned from the
SHLoadIndirectString API.
Previously, the output buffer was converted to string using
Span<char>.ToString() without trimming at the null terminator (\0). As a
result, the entire buffer (1024 characters) was converted, including
trailing garbage data after the valid string.
This caused the fuzzy matching logic to process unnecessarily long
strings, leading to excessive CPU usage and input lag (~2 seconds delay
per keystroke).
The fix properly locates the first null terminator in the buffer and
slices the span before converting to string, eliminating trailing
garbage characters. This reduces the workload in the scoring function
and resolves the input lag in the apps extension search.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #40197
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
We need to sign for all dll in our pipeline. But I forgot to do it in
the last PR.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Co-authored-by: Yu Leng <yuleng@microsoft.com>
## Summary of the Pull Request
found this bad link, fixing it to help others
## Validation Steps Performed
Used markdown preview in VSCode, clicked the link, it works!
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Root Cause:
After the CsWin32 upgrade, the code switched from using manually
allocated unmanaged buffers (Marshal.AllocHGlobal) to using Span<char>
via outBuffer.AsSpan(). However, the Span length passed to
SHLoadIndirectString was not correctly calculated.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Telemetry.write will serialize all of the whole object graph. So we need
to ensure it will not be trimmed.
This is a safe PR because it doesn't apply any logic change. If you
disable the AOT feature, this PR won't take any effect.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #40149
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
### 1. Make AdaptiveCards WinUI3 AOT Compatible
The AdaptiveCards.WinUI3 NuGet packages ship with precompiled WinRT
projections (RendererCsProjection.dll, etc.), which are not
trim/AOT-safe. These projections internally use APIs like
ComWrappersSupport.GetObjectReferenceForInterface, which break under
PublishAot.
To resolve this:
- We exclude their compile assets to avoid using the shipped C#
projections.
- Use the .winmd metadata files with CsWinRT to regenerate our own
AOT-compatible projections.
- Manually copy the required native .dlls from the NuGet package.
### 2. Ensure AOT-Compatible Transitive Dependency
The AdaptiveCards.Templating package depends on
Microsoft.Bot.AdaptiveExpressions.Core, but doesn’t pin an AOT-safe
version. We explicitly version Microsoft.Bot.AdaptiveExpressions.Core to
4.23.0 to ensure compatibility with NativeAOT.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:**
[#40133](https://github.com/microsoft/PowerToys/issues/40133)
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Update private notification and ado assignment email to
PowerToys@microsoft.com
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [X] **Closes:** #40103
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Base on this discussion:
https://github.com/microsoft/PowerToys/pull/39800
Currently, Flush still have some problem to use it. So, we need to
consider to disbale it.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
To avoid dup code, try to move some LibraryImport define to common
folder.
This can make other modules/extensions easy to use.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
CsWin32 0.3.183 broke preview through preview handlers in Peek.
`Error in UpdatePreviewAsync, falling back to default previewer: Unable
to cast COM object of type 'System.__ComObject' to class type
'System.IntPtr'. Instances of types that represent COM components cannot
be cast to types that do not represent COM components; however they can
be cast to interfaces as long as the underlying COM component supports
QueryInterface calls for the IID of the interface.`
Signature of `CoGetClassObject` changed for last argument from `void*`
to `object`.
Thanks @AArnott 🙂
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Tested Preview of Office files in Peek.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This actually fixes an issue with #39794. What I failed to mention in
the original issue was the additional path under the registry that the
new key is located under. Instead of the key being stored directly in
`UserChoiceLatest` in a key named `ProgId`, the path also includes a
second `ProgId` as well.
Copilot tried to fix this issue in #40035, but because I had failed to
mention the additional `ProgId` in the path, it was not included in
Copilot's fix.
Therefore, the true new path is
`.../UserChoiceLatest/ProgId`
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39794
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
We are missing msix setup event log from
Microsoft-Windows-AppXDeploymentServer-Operational from bug report.
This PR includes it back for any installation with Powertoys or
CommandPalette
Attach the sample one capture after I setup PowerToys for
Microsoft-Windows-AppXDeploymentServer-Operational events
[EventViewer-AppXDeploymentServerEventLog.zip](https://github.com/user-attachments/files/20791324/EventViewer-AppXDeploymentServerEventLog.zip)
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## Summary
This PR fixes an issue where PowerToys Web Search and PowerToys Run
would always open Microsoft Edge instead of the user's default browser
on Windows 11 24H2, even when a different browser like Firefox was set
as the default.
## Root Cause
Windows 11 24H2 introduced a change where default browser associations
are now stored in a new registry location:
- **New location**:
`HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoiceLatest`
- **Old location**:
`HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice`
PowerToys was only checking the old registry location, causing it to
fail to find the default browser and fall back to Microsoft Edge.
## Changes Made
Updated both `DefaultBrowserInfo.cs` files to check the new registry
location first, then fall back to the old location for backward
compatibility:
1. **Command Palette Web Search**:
`src/modules/cmdpal/ext/Microsoft.CmdPal.Ext.WebSearch/Helpers/DefaultBrowserInfo.cs`
2. **PowerToys Run**:
`src/modules/launcher/Wox.Plugin/Common/DefaultBrowserInfo.cs`
**Before**:
```csharp
var progId = GetRegistryValue(
@"HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice",
"ProgId");
```
**After**:
```csharp
var progId = GetRegistryValue(
@"HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoiceLatest",
"ProgId")
?? GetRegistryValue(
@"HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice",
"ProgId");
```
## Testing
- Verified the fallback logic works correctly with a test application
- Confirmed both affected files are updated with the same pattern
- Ensured backward compatibility with older Windows versions
## Impact
This fix ensures that:
- Users on Windows 11 24H2 will have their default browser respected
- Older Windows versions continue to work as before
- No breaking changes are introduced
Fixes#39794.
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: crutkas <1462282+crutkas@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR updates all application manifest files across the PowerToys
codebase to use **PerMonitorV2** DPI awareness, ensuring optimal
high-DPI display support on modern Windows systems.
## Changes Made
Updated **12 manifest files** to include proper PerMonitorV2 DPI
awareness:
### Files with New DPI Support Added:
- `src/runner/PowerToys.exe.manifest` - Added complete DPI awareness
section
- `src/modules/awake/Awake/app.manifest` - Upgraded from basic
`dpiAware` to PerMonitorV2
### Files Upgraded from PerMonitor to PerMonitorV2:
- `src/modules/colorPicker/ColorPickerUI/App.manifest`
- `src/modules/MouseWithoutBorders/App/MouseWithoutBorders.exe.manifest`
### Files Enhanced for Consistency:
- `src/modules/ShortcutGuide/ShortcutGuide/ShortcutGuide.exe.manifest`
- `src/modules/ZoomIt/ZoomIt/Zoomit.exe.manifest`
- All 5 cmdpal extension manifests
## Technical Implementation
All manifests now use the standardized format that provides:
1. **PerMonitorV2** as the primary DPI awareness mode for Windows 10
Anniversary Update and later
3. **`true/PM`** for backward compatibility with pre-Windows 10 systems
```xml
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/PM</dpiAware>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, PerMonitor</dpiAwareness>
</windowsSettings>
</application>
```
## Screenshot for comparision:
Before:

After:

---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Remove throw exception and add some logs here.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #xxx
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** Added/updated
- [x] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [x] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Removes extra call to Marshal.GetIUnknownForObject. This method is meant
to take a .NET object that implements a COM interface and return a
pointer to a COM instance that can be passed to native COM code, but the
code was passing a COM instance pointer.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [X] **Closes:** No associated issue
- [X] **Communication:** Working with @moooyo on AOT and COM
- [X] **Tests:** No change in behavior expected, so no new tests
- [X] **Localization:** No new strings
- [X] **Dev docs:** No change in behavior
- [X] **New binaries:** none
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Workspace support for pwa is now limited, it is tight to specific
Profile launch. If you create a pwa app with a profile other than
"Default", launch will fail. Then you have to manually configure that
profile to launch.
This pr fix it by launching with shell:appsfolder\appusermodelId
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [X] **Closes:** #36384
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- [X] Create a new workspace with a pwa app(Other than default profile)
should be no problem.
- [X] Existing workspace with a pwa(default profile and other profile)
should launch successfully without problem
1. with pt version 91.1, create a loop pwa with "Profile 1" instead of
"Default" in edge.
2. capture and launch actually launch the edge instead of loop
3. Create profile with this impl and launch
4. Launch pwa successfully
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
### <!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
### Bug report tool status tracking:
Currently, After clicking the generate package button, button is still
active, as we do not have bug report progress, this will confuse user
whether they actually clicks the button.
Add an enable status to acknowledge the bug generating
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
1. Progress bar should be present in generating report place when there
is bug report going on.
2. Runner&Settings should know each other when they trigger the bug
report.
3. Runner tray icon menu item should be disabled when there is one bug
report going on.
4. After bug report generation, everything should be like before.
## Validation Steps Performed
https://github.com/user-attachments/assets/dcbf8e6e-c5e1-4d23-9dab-f16c11ed56cf
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This is an additional fix that extends the work done in
https://github.com/microsoft/PowerToys/pull/40023fix#39851
## Problem
[PdfThumbnailProvider](cci:1://file:///d:/Github/PowerToys/src/modules/previewpane/PdfThumbnailProvider/PdfThumbnailProvider.cs:15:8-18:9)
could fail at compile-time **and/or** produce empty or invalid
thumbnails at runtime:
1.
[Image](cci:1://file:///d:/Github/PowerToys/src/modules/previewpane/PdfThumbnailProvider/PdfThumbnailProvider.cs:81:8-103:9)
/ `Bitmap` types come from **System.Drawing**, but the namespace was
missing, causing build errors in environments that don’t rely on
implicit global usings.
2. After rendering the first PDF page to an in-memory stream, the
stream’s cursor remained at the end.
`Image.FromStream(stream.AsStream())` therefore read **zero bytes**,
throwing an exception or creating an empty bitmap.
## Fix
* Added explicit `using System.Drawing;`.
* Added `stream.Seek(0);` right before `Image.FromStream(...)` to rewind
the stream to the beginning.
```csharp
using System.Drawing; // new
...
page.RenderToStreamAsync(...).GetAwaiter().GetResult();
stream.Seek(0); // rewind so Image.FromStream reads data
imageOfPage = Image.FromStream(stream.AsStream());
```
## Testing
- Rebuilt the solution – compilation succeeds without missing-namespace
errors.
- Ran thumbnail handler against multiple PDFs; thumbnails now render
correctly and no runtime exceptions are thrown.
## Impact
Users regain reliable PDF thumbnail previews in Explorer, improving
usability and preventing crashes or blank icons.
---------
Co-authored-by: leileizhang <leilzh@microsoft.com>
## Summary of the Pull Request
Theme aware cropped windows.
## PR Checklist
- [x] **Closes:** #28348
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
## Detailed Description of the Pull Request / Additional comments
Added a Theme aware implementation that was already found on other
components, the only difference is that we are dealing with multiple
windows.
It will follow the Power Toys application theme, (windows too in case
PowerToys follows the System).
I decided to change the scope of a variable to not create a second
control of croppedWindows, this may need to be taken into consideration.
## Validation Steps Performed
Using Crop (Win + Ctrl + Shift +R)
Crop one or multiple windows.
All of them have the same theme as the application.
Went to windows theme settings, change to light theme, the app changes
accordingly.
Same behavior was tested with Thumbnail (Win + Ctrl + Shift + T)
Closing windows and changing the theme again.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
### This PR implements various fixes and improvements into
RegistryPreview for saving files:
1. Adds an unsaved file indicator in the title bar like in Notepad. (As
indicator we show the * character before the file title.)
2. The save button behaves like a "save as" button, if the file does not
exist on disk like in Notepad. (Without fix when running as non-admin
you get an access denied error message.)
3. If the app gets closed without saving and the file does not exist on
disk, then the user is now asked for the path. (Fixes crash on clicking
save button while closing the app.)
4. Failed save actions are handled now correctly on dirty closing,
opening files and all other actions that require saving the current
state. They will stop the process.
5. A fix for an incorrect enabled state of the save button after
opening, reloading and saving a file.
6. Reuse file name on save as button, if known. Otherwise use "new file"
template name like in Notepad.
7. Fix an app crash if you click the window's close button a second time
while the "Should save?" dialog is opened.
8. Added an reload dialog in case of unsaved changes.


<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #36876, #36875
- [x] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Local test build.
---------
Co-authored-by: Gordon Lam (SH) <yeelam@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
The fallback items of Time & Date plugin missing the command. This PR
add the missing copy command.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #40029
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
- Adds a new **"Restart Windows Explorer"** command to the **"Windows
System Commands"** provider
- Implemented using **Restart Manager** to allow restoring previously
opened Explorer windows after restart
- This depends on the *"Restore previous folder windows at logon"*
option in File Explorer Options
- An explicit timeout was added for terminating processes, since Restart
Manager uses very long timeouts 😴
- The shell process name (`explorer`) is hardcoded
- The command attempts to terminate all `explorer` processes
indiscriminately
- Execution requires confirmation (if enabled in settings)

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #39213
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
The results in Time&Date ext are cached. This leads to outdated results
and makes no sense for a time/date query.
The PR fixes this.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39973
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Add a version project reference to the CalculatorEngineCommon project to
integrate versioning support.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Fixed build warnings WMC1510 in `HostsMainPage.xaml` that were
preventing proper AOT (Ahead-of-Time) compilation compatibility for XAML
data bindings.
### Problem
The Hosts module was generating multiple WMC1510 warnings during build:
```
src\modules\Hosts\HostsUILib\HostsMainPage.xaml(614,13): Warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive...
```
These warnings occurred on 6 different binding expressions in the
EntryDialog ContentDialog that bound to properties of the `Entry` model
class.
### Solution
Applied the recommended fix by adding proper type information for the
XAML compiler:
1. **Added `x:DataType="models:Entry"`** to the ContentDialog element to
specify the binding context type
2. **Added `[Bindable]` attribute** to the Entry model class to ensure
WinRT compatibility
### Changes Made
- **HostsMainPage.xaml**: Added `x:DataType="models:Entry"` attribute to
the EntryDialog ContentDialog
- **Entry.cs**: Added `[Bindable]` attribute and `using
Microsoft.UI.Xaml.Data;` directive
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
- ✅ Resolves all 6 WMC1510 warnings in the specified lines
- ✅ Ensures AOT compilation compatibility
- ✅ No functional changes to UI behavior
- ✅ Minimal code changes (3 lines total)
- ✅ Follows Microsoft's recommended approach for WinRT data binding
The fix enables proper trimming and AOT compilation while maintaining
all existing functionality.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Try to build and run locally without problem.
## Summary of the Pull Request
Adds a *Learn more* link pointing
[here](https://aka.ms/PowerToysOverview_HostsFileEditor) (the same as in
the settings) to the warning dialog that shows up when Hosts File Editor
starts
## PR Checklist
- [x] **Closes:** #39859
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end user facing strings can be localized
- [x] **Dev docs:** No need
- [x] **New binaries:** None
- [x] **Documentation updated:** No need
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Tested the UI manually
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR fixes an issue where the warning message in Peek was always
displayed, even when not applicable.
**Root cause**
When non-video files were triggered, the logic did not call
`IsWarningMessageVisible(string? missingCodecName)`
as expected. As a result, the default UI state caused the warning
message to always appear.
**Fix**
Updated the method signature and call sites to:
`public Visibility IsWarningMessageVisible(IPreviewer? previewer,
PreviewState? state)`
This ensures that the logic is consistently triggered across different
preview handlers and has access to the necessary context to determine
whether the warning message should be shown.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
FontIcon will be trimmed, we need to create a rd.xml to keep them.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #40057
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Co-authored-by: Yu Leng <yuleng@microsoft.com>
This reverts commit 7d257cf00c due to a
security concern involving multiple feeds
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
Adds a *Copy path* command to the <kbd>Ctrl</kbd>+<kbd>K</kbd> menu in
the All apps extension
## PR Checklist
- [x] **Closes:** #39500 (as mentioned in the discussion, the other
requests will be tracked over in #39501)
- [x] **Communication:** I've discussed this with core contributors
already + has Help wanted
- [x] **Tests:** All pass
- [x] **Localization:** All end user facing strings can be localized
- [x] **Dev docs:** No need
- [x] **New binaries:** None
- [x] **Documentation updated:** No need
## Detailed Description of the Pull Request / Additional comments
Copies the exe full path for standard programs. Copies the package
directory for UWPs.
Shows a *Copied to clipboard!* toast on a successful copy and closes.
Shows a toast when copying fails, keeps CmdPal open.

## Validation Steps Performed
Manually tested copying for UWPs and Win32 programs
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
CmdPal is leaking extensions processes as the process is immediately
killed.
This PR fixes the 1.5s wait for the process to end correctly and also
close extensions.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- Verified that if CmdPal closes in 1.5s, extensions and process are
closed (note that GitHub extension doesn't close probably due to
https://github.com/microsoft/PowerToys/pull/39209)
- Verified that if CmdPal doesn't close in 1.5s the process is killed
and extensions aren't closed (tested adding a delay in the code)
## Summary of the Pull Request
Enables the users to choose what left, right, and middle click does when
color picker is open.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39006
- [x] **Communication:** I've discussed this with core contributors
already
- [x] **Tests:** All pass
- [x] **Localization:** All end user facing strings can be localized
- [x] **Dev docs:** No need
- [x] **New binaries:** None
- [x] **Documentation updated:** No need
## Detailed Description of the Pull Request / Additional comments

Adds option to choose from 3 click behaviors for each standard mouse
button:
* **Pick color and open editor**: Copies color to clipboard, saves it to
the color history and opens the editor
* **Pick color and close**: Copies color to clipboard, saves it to the
color history and exits
* **Close**: Closes color picker without copying the color
Pressing <kbd>Enter</kbd> or <kbd>Space</kbd> does what clicking the
primary button would.
Left and middle click actions execute on mouse down, right click on
mouse up for reasons discussed previously (I can't find the conversation
now)
Default settings are chosen in such a way that very little or nothing
changes by updating.
## Validation Steps Performed
Tested:
* Migrating settings from v2.0 to v2.1 (v1 to v2.1 not tested)
* Settings page displays and saves settings correctly
* Default settings load correctly
* All three click actions do what they are supposed to
* Activation behavior works as expected, doesn't affect click actions
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR replaces the original Mages-based expression evaluation engine
with a WinRT-wrapped version of Exprtk in the CmdPalCalculator module.
### Key Changes
**Expression Engine:**
- All expression parsing and evaluation now use Exprtk (via a WinRT
wrapper) instead of Mages.
**Base Conversion Handling:**
- Since Exprtk does not support non-decimal (binary, octal, hexadecimal)
input natively, added logic to convert all such inputs to decimal before
evaluation.
**Code Structure:**
- The overall logic and API surface remain unchanged except for the
engine and base conversion handling.
- All previous Mages references and dependencies have been removed.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
This pull request introduces a new unit testing framework for the
`WorkspacesLib` module, adds test coverage for various utilities, and
integrates the new test project into the build system. Key changes
include adding the `WorkspacesLibUnitTests` project, implementing tests
for `AppUtils`, `JsonUtils`, and `PwaHelper`, and updating the build
configuration to include the new test project.
### Unit Tests Added:
* **`AppUtilsTests`**:
- Added comprehensive tests for methods such as `GetCurrentFolder`,
`IsEdge`, `IsChrome`, and `IsSteamGame` to validate their behavior under
various conditions.
* **`JsonUtilsTests`**:
- Implemented tests for reading and writing workspace data, including
scenarios for invalid JSON, non-existent files, and valid workspace
lists.
* **`PwaHelperTests`**:
- Added tests to ensure the stability of `PwaHelper` methods, such as
`GetEdgeAppId`, `GetChromeAppId`, and `SearchPwaName`, even with invalid
or empty inputs.
### Build System Updates:
* **New Test Project Integration**:
- Added the `WorkspacesLibUnitTests` project to the solution file
`PowerToys.sln` with appropriate dependencies.
- Updated build configurations to include the new test project for both
Debug and Release builds across architectures.
[[1]](diffhunk://#diff-ca837ce490070b91656ffffe31cbad8865ba9174e0f020231f77baf35ff3f811R2208-R2215)
[[2]](diffhunk://#diff-ca837ce490070b91656ffffe31cbad8865ba9174e0f020231f77baf35ff3f811R2841)
### Pipeline Adjustments:
* **Test Discovery**:
- Updated the pipeline configuration in
`.pipelines/v2/templates/job-build-project.yml` to discover the new
`WorkspacesLibUnitTests.dll` during test runs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Enable dpi aware of FancyZone Editor.
Context:
I happened to drag the editor window to my other monitor that has a
different dpi, and the text are blurry.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual.
Few updates to the WinGet publish workflow action
- Use GitHub release event instead of manually making an API call to
GitHub API and then fetching the target release. The target release is
directly accessible via the event. The refactor is similar to the GitHub
action of
[microsoft/edit](https://github.com/microsoft/edit/blob/main/.github/workflows/winget.yml)
repo's workflow
- With the latest winget-create release, the preferred method for
providing the GitHub token in CI/CD environment is via the environment
variable `WINGET_CREATE_GITHUB_TOKEN`. Removed use of `--token` and
switched to environment variable. See https://aka.ms/winget-create-token
for details.
They made secure strings the default. Doing it this way maintains
compatibility with the version before and after the default changed.
This fixes symbol publication.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
The `verifyNoticeMdAgainstNugetPackages.ps1` script previously only
reported "Notice.md does not match NuGet list." without providing any
details about which packages were different, making it difficult to
debug discrepancies.
## Changes Made
This enhancement adds detailed difference reporting when NuGet packages
don't match:
- **Extracts current package list from NOTICE.md** using regex pattern
matching
- **Shows packages missing from NOTICE.md** (highlighted in red)
- **Shows packages in NOTICE.md but not in generated list** (highlighted
in yellow)
- **Provides summary statistics** with package counts
- **Maintains backward compatibility** - all existing functionality
preserved
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
If there is no difference, the same behaviour.
If there is difference, here is the example:

## Edge Cases Handled
- **Missing NuGet section**: Shows warning and treats as empty package
list
- **Empty package lists**: Handles gracefully with appropriate counts
- **Matching lists**: No additional output (preserves existing behavior)
This enhancement significantly improves the debugging experience when
NuGet package verification fails by providing specific, actionable
information about which packages need attention.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Fixes spelling issues and spell checker warnings
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Updates .NET 9 Runtime / Library packages to the latest 9.0.6 servicing
release for security fixes.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
This PR also updates the version of System.Text.Json to 9.0.6 in the
CmdPal extension template.
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Gordon Lam (SH) <yeelam@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This PR applies a series of grammar, punctuation, and stylistic updates
across the main README and GitHub templates to improve consistency,
clarity, and alignment with formatting guidelines.
### File-Level Changes
| Change | Details | Files |
| ------ | ------- | ----- |
| Updated README.md for grammar, punctuation, and phrasing consistency |
<ul><li>Inserted missing commas and adjusted articles for clearer
sentences</li><li>Standardized hyphenation and removed extra spaces
around slashes</li><li>Refined bullet list punctuation and corrected
pluralization (‘number of bugs’)</li></ul> | `README.md` |
| Refined pull request template text for clarity and uniform formatting
| <ul><li>Hyphenated “end-user-facing” and added Oxford comma in
checklist items</li><li>Adjusted phrasing in communication bullet for
parallel structure</li><li>Reworded placeholder comment for detailed PR
description</li></ul> | `.github/pull_request_template.md` |
| Standardized issue templates with grammar and placeholder improvements
| <ul><li>Clarified label descriptions and added missing commas in
placeholders</li><li>Unified question phrasing across bug, feature,
translation, and docs templates</li><li>Corrected capitalization and
refined instructions for consistency</li></ul> |
`.github/ISSUE_TEMPLATE/bug_report.yml`<br/>`.github/ISSUE_TEMPLATE/feature_request.yml`<br/>`.github/ISSUE_TEMPLATE/translation_issue.yml`<br/>`.github/ISSUE_TEMPLATE/documentation-issue.yml`
|
---
## PR Checklist
- [ ] **Closes:** #xxx
- [X] **Communication:** I've already discussed this with core
contributors. If the work hasn't been agreed, this work might be
rejected
- [X] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [X] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here:
https://github.com/MicrosoftDocs/windows-dev-docs/pull/5447
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Jay <65828559+Jay-o-Way@users.noreply.github.com>
This PR introduces the **Definition** plugin—a new PowerToys Run
extension that allows you to quickly lookup word definitions, phonetics,
and synonyms without leaving your keyboard.
🔗 **Learn more**
| Plugin | Author | Description |
|:-------|:------:|:------------|
| [Definition](https://github.com/ruslanlap/PowerToysRun-Definition) |
[ruslanlap](https://github.com/ruslanlap) | Lookup word definitions,
phonetics, and synonyms without leaving your keyboard. |
---
## ✨ Features
- **Instant Definitions**
Get definitions in real-time via dictionaryapi.dev.
- **Pronunciation Audio**
Play phonetic audio directly from your results.
- **Phonetics & Synonyms**
View phonetic spelling, synonyms, and antonyms.
- **Usage Examples**
See real-world examples of how words are used.
- **Delayed Execution**
Shows loading indicator before fetching results.
- **Caching**
In-memory cache for repeat lookups (up to 100 entries) to improve
performance.
- **Theme Awareness**
Automatically switches icons for light/dark mode.
- **Context Menu**
Copy definitions, play pronunciation, open source URL, or search for
related words via right-click or keyboard shortcuts.
- **Cancellable Requests**
Automatically cancels previous requests when typing new queries.
- **Wiktionary Integration**
Open any word in Wiktionary for additional information and translations.
---
Thank you for reviewing the **Definition** plugin! 📚
I'm excited to help PowerToys Run users look up words faster than ever.
# 🚀 Add SpeedTest Plugin for PowerToys Run
This PR introduces the **SpeedTest** plugin—a new PowerToys Run
extension that lets you run internet speed tests instantly, without
opening a browser or separate application. Also was problem with
formating previous Plugin "Linear"
🔗 **Learn more**
| Plugin | Author | Description |
|:-------|:------:|:------------|
| [SpeedTest](https://github.com/ruslanlap/PowerToysRun-SpeedTest) |
[ruslanlap](https://github.com/ruslanlap) | One-command internet speed
tests with real-time results, modern UI, and shareable links. |
---
## ✨ Plugin Highlights
- **One-command tests**
Run a full speed test (download, upload, ping, server) via PowerToys Run
(). and hit Enter! (or change to or any other keyword in the settings)
- **Modern, theme-aware UI**
WPF-based window adapts automatically to light or dark Windows modes.
- **Live progress & shareable links**
Watch your test run in real time and copy a result URL when it finishes.
- **All-local, privacy-first**
No third-party tracking—uses the bundled Speedtest CLI for 100% local
execution.
- **Robust error handling**
Friendly messages for network failures, permission issues, or unexpected
errors.
- **x64 & ARM64 builds**
Native-optimized releases for both CPU architectures.
- **Open source & community-driven**
Contributions, issues, and feature requests are welcome—let's make it
even better!
---
Thank you for reviewing the **SpeedTest** plugin! 🚀
I'm excited to help PowerToys Run users check their internet speeds
faster than ever.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Problem
-------------
We've observed multiple bug reports related to crashes with the
following exceptions:
System.Runtime.InteropServices.COMException (0xD0000701)
System.Runtime.InteropServices.COMException (0x80263001)
The root cause of these crashes has been traced to the WPF framework,
specifically this line in WindowChromeWorker.cs:
3439f20fb8/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/WindowChromeWorker.cs (L1005)
These crashes are not necessarily caused by PowerToys Run itself being
used, or even visible. However, users perceive them as Run-related
because the "Report problem UI" is triggered by our global exception
handler, surfacing the underlying WPF crash.
Fix
------------
This PR:
- Suppresses the launch of the "Report problem UI" for exceptions known
to be triggered by unstable platform conditions (such as COMExceptions
from WPF internals).
- Continues to log the exception to preserve diagnostic data.
This change ensures we:
- Avoid showing an UI when WPF framework itself is already having
problem to handling DWM composition changes.
This lets us auto-focus the first input on a `IFormContent`, if there's
only one `IContent` on the page.
This dramatically improves the usability for forms, since we'll
immediately put focus into them
Closes#38436
<!-- Let's say you wanted to add a hotkey to the Run command. And let's
say you wanted it to be Win+R. This lets you do that -->
We should apply the LLKH setting to all command hotkeys, not just the
global one.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Using the
[Microsoft.Windows.Settings](https://www.powershellgallery.com/packages/Microsoft.Windows.Settings/)
module is the now the recommended way of configuring Windows Settings,
including developer mode.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Verified that setting developer mode with the new resource works as
intended
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR adds support for detecting missing video codecs during video
file preview, and displays a warning message to inform the user when the
required codec is not installed.
### Changes
- Added `GetMissingCodecAsync` to detect unsupported video formats using
`MediaEncodingProfile` and `CodecQuery`.
- If a required codec is missing, display a warning in the preview UI.
- Added localized string `MissingVideoCodec_WarningMessage`:
> "This video uses the {0} format, which isn't supported. Please install
the required codec to play it."
- Add Store Search


<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** https://github.com/microsoft/PowerToys/issues/39235,
https://github.com/microsoft/PowerToys/issues/38201
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [x] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
To simulate a missing codec (e.g., AV1):
1. Check if the AV1 extension is installed:
```powershell
Get-AppxPackage -Name *AV1*
2. If installed, remove it:
```powershell
Get-AppxPackage -Name *AV1* | Remove-AppxPackage
3. Use Peek to preview a video encoded in AV1 format.
4. Confirm that a warning message is shown indicating the missing codec.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
<img width="151" alt="image"
src="https://github.com/user-attachments/assets/994c06d0-e28f-4fa4-a8fe-043ec179ee82"
/>
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #38303
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
- Move all system tray related code from main window code behind to a
dedicated service
- Add system tray menu
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manually tested:
- Started CmdPal with tray icon enabled
- Started CmdPal with tray icon disabled
- Enabled/Disabled tray icon
- Tested tray menu commands
- Verified that the tray icon is visible after restarting explorer.exe
Adding Jessica and Michael to community.md
demoting myself to overhead :)
---------
Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com>
Co-authored-by: Mike Griese <migrie@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
We need to release it manually.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This change replaces the manual .lib reference with a proper project
reference to PowerRenameLib in the PowerRename.FuzzingTest project.
Previously, the project used a hardcoded path to link against
PowerRenameLib.lib, which caused build errors in Debug mode when the
.lib file had not yet been generated or the output path was incorrect.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR introduces necessary changes to make the CmdPal.Apps extension
compatible with NativeAOT publishing. The main updates include:
1. Project configuration updates: Added NativeAOT-related properties to
the .csproj.
2. Native interop adjustments:
> - Introduced NativeMethods.json and used
[CsWin32](https://github.com/microsoft/cswin32) to generate P/Invoke
bindings.
> - Replaced some DllImport declarations with source-generated
[LibraryImport] for improved AOT support.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
* Use source generation to replace some csWin32 function call.
* Clean up some AOT compatible issues.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39889
- [x] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
If you want to try it out, please see
https://github.com/microsoft/PowerToys/pull/39605
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Changes my old name to my new name in community.md and the File Explorer
add-ons attribution.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Base on my test, some built-in extensions can be published with native
AOT enabled with a little changes. (see this branch:
https://github.com/microsoft/PowerToys/pull/39605).
1. SystemCommands: no change need. Removed some unused code.
2. WinGet: disable marshalling. and do a little changes in
CreateInstance.
3. WindowWalker: use source generation to call CoCreateInstance.
4. WindowsTerminal: use source generation to call
IApplicationActivationManager interface.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39869
- [x] **Communication:** I've discussed this with core contributors
already. If work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** All end user facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR mainly add comments in
src/modules/AdvancedPaste/AdvancedPaste/Strings/en-us/Resources.resw to
solve issues raised by localization team.
---------
Co-authored-by: ArleneYu <yuzw@pku.edu.cn>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Minor typo it's -> its
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
<!-- Provide a more detailed description of the PR, other things fixed
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
README-only change
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
n/a
* Added option to toggle the system tray icon
At the moment, this hides the icon making the settings window inaccessible without first modifying the general `settings.json` file.
* Use IPC messages to manage the tray icon settings
* Fix launching second window binds to active settings process
* Added context menu option to hide tray icon
* Added Exit PT button to settings ui NavigationView.PaneFooter
* Moved DllImports to NativeMethods.cs
* Sentence case titles
* Fix whitespace
* Re-add exit icon to NavView
* Re-added toggle switch to new UI
* Fix build
* Fix build after merge main
* Fix the string to display
* add shut down buttons
* finish polish
* fix string
* Styling tweaks to titlebar and settingscards
* fix comment
* fix unit test
* fix ut
---------
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: vanzue <vanzue@outlook.com>
Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
This was especially noticable with the icons extension.
Turns out in #39051, when I was experimenting with getting AoT clean,
i accidentally called this twice. Then we actually commited that
straight up.
This PR reverts that. It also moves a similar case where we were
initializing all the tags on the UI thread. That's wrong too - we need
to fetch properties off the UI thread, then update the list on the UI
thread.
Closes nothing, I didn't file this yet.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Since we change the launch method by this PR #39269 , we will start cmdpal as admin too if powertoys run as admin.
The fix is leveraging explorer (which will not run as admin) to start the cmdpal
Moreover, without this fix, some of extension cannot be "loaded" when cmdpal run as admin, e.g. winget will be missing, and my own new extension developed by myself will not be loaded successful as well.
Strong-name signing embeds publisher identity into the signature of a
.NET assembly.
This is required if *any other* strong name signed project wants to take
a dependency on it.
To make this work, we need to delay-sign it with a public key (.snk
file)--e.g. say we are going to sign it, but not actually sign it--to
give it an identity and then later submit it to ESRP for final signing.
The snk file does not contain any private material.
Some minor changes were required to build properly:
- `InternalsVisibleTo` requires a PublicKeyToken, but we aren't using
it in the SDK build so it's fine to just leave it out.
- I had to mark a class `sealed` and I can only guess it's because
strong named assemblies have more guarantees?
* Update version to 0.91
Update version to 0.91
* Some PRs are still not included.
Some PRs are still not included.
* Add some PRs
* Add more PRs
* Add more PRs
* Add two more PRs
* Add some PRs
* Add one more PR
* Add all PRs up to this point, except for some documentation-related ones.
* Add the Highlights part
* Overall edits
* Add PRs about Doc changes
* Clean up the highlights section
* Update MD5
* Changed highlights and removed reg preview line item
* Put reg preview item back and updated highlights
---------
Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com>
## Summary of the Pull Request
The Command Palette allows users to create extensions with dashes in their names, which is invalid for C# namespaces. This causes projects to fail during build because the name cannot be used as a valid namespace.
## Changes
- Updated the validation regex in `NewExtensionForm.cs` to only allow valid C# identifiers
- Now only allows names starting with a letter or underscore, followed by letters, numbers, or underscores
- Explicitly prevents dashes, spaces, and other special characters
- Improved the error message to clearly explain the requirements for valid C# identifiers
## Before
Previously, the input only validated that no spaces were used:
```csharp
"regex": "^[^\\s]+$"
```
## After
Now the input properly validates for C# namespace compatibility:
```csharp
"regex": "^[a-zA-Z_][a-zA-Z0-9_]*$"
```
This ensures that users cannot create extension projects with names that would fail to build.
## PR Checklist
- [ ] **Closes:** https://github.com/microsoft/PowerToys/issues/38522
This will ensure that the command palette package is copied to the artifact directory.
If code signing was enabled, the final copied package will be the signed version.
Minor build rule rearranging was required to collect the command palette package
path for the staging step when signing was _disabled_. I did this solely so that we
could verify the results in CI.
This pull request adopts the unified versioning scheme used by Windows Terminal, Notepad, and hundreds of other internal and public projects that relied on "XES" or "PackageES".
It only does so for the command palette.
All command palette assets will be versioned according to the Major and Minor number in `src/modules/cmdpal/custom.props`. This includes DLLs, EXEs, NuGet packages and MSIX bundles.
This will ensure that all artifacts that we produce are versioned
properly:
| thing | version (ex.) |
|---------|-----------------|
| dll/exe | 0.2.2505.08001 |
| nupkg | 0.2.250508001 |
| appx | 0.2.3269.0 |
For reference, here's the version format:
### EXE, DLL, .NET Assembly
0.2.2505.08001
^ ^ ^ ^ ^ ^
| | | | | `-Build # on that date
| | | | `-Day
| | | `-Month
| | `-Year
| `-Minor
`-Major
### NuGet Package
0.2.250508001
^ ^ ^ ^ ^ ^
| | | | | `-Build # on that date
| | | | `-Day
| | | `-Month
| | `-Year
| `-Minor
`-Major
### AppX Package
0.2.01281.0 (the leading 0 will be removed)
^ ^ ^ ^^ ^
| | | || `-Contractually always zero (a waste)
| | | |`-Build # on that date
| | | `-Number of days in [base year]
| | `-Number of years since [base year]
| `-Minor
`-Major
[base year] = $(XesBaseYearForStoreVersion)
It is expected that the base year is changed every time the version
number is changed.
@@ -35,19 +35,19 @@ Microsoft PowerToys is a set of utilities for power users to tune and streamline
Go to the [Microsoft PowerToys GitHub releases page][github-release-link] and click on `Assets` at the bottom to show the files available in the release. Please use the appropriate PowerToys installer that matches your machine's architecture and install scope. For most, it is `x64` and per-user.
<!-- items that need to be updated release to release -->
@@ -85,7 +85,7 @@ We ask that **before you start work on a feature that you would like to contribu
Most contributions require you to agree to a [Contributor License Agreement (CLA)][oss-CLA] declaring that you grant us the rights to use your contribution and that you have permission to do so.
For guidance on developing for PowerToys, please read the [developer docs](/doc/devdocs) for a detailed breakdown. This includes how to setup your computer to compile.
For guidance on developing for PowerToys, please read the [developer docs](./doc/devdocs) for a detailed breakdown. This includes how to setup your computer to compile.
## What's Happening
@@ -93,166 +93,138 @@ For guidance on developing for PowerToys, please read the [developer docs](/doc/
Our [prioritized roadmap][roadmap] of features and utilities that the core team is focusing on.
### 0.91 - May 2025 Update
### 0.92 - June 2025 Update
In this release, we focused on new features, stability, and automation.
In this release, we focused on new features, stability, optimization improvements, and automation.
**✨Highlights**
-We focused on greatly improving the Command Palette's performance and fixing a large number of bugs. Some new features we've added are:
-Added the ability for Command Palette to search any file using a fallback command.
-Added the ability to make the Command Palette global hotkey a low-level keyboard hook.
-Added open URL fallback command for the WebSearch extension, enabling users to directly open URLs in the browser from Command Palette.
-You can now define custom formats in the Date and Time plugins of PT Run and Command Palette. Thanks [@htcfreek](https://github.com/htcfreek)!
### Advanced Paste
- Fixed an issue where Advanced Paste failed to create the OCR engine for certain English language tags (e.g., en-CA) by initializing the OCR engine with the user profile language. Thanks [@cryolithic](https://github.com/cryolithic)!
-PowerToys settings now has a toggle for the system tray icon, giving users control over its visibility based on personal preference. Thanks [@BLM16](https://github.com/BLM16)!
-Command Palette now has Ahead-of-Time ([AOT](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot)) compatibility for all first-party extensions, improved extensibility, and core UX fixes, resulting in better performance and stability across commands.
-Color Picker now has customizable mouse button actions, enabling more personalized workflows by assigning functions to left, right, and middle clicks. Thanks [@PesBandi](https://github.com/PesBandi)!
-Bug Report Tool now has a faster and clearer reporting process, with progress indicators, improved compression, auto-cleanup of old trace logs, and inclusion of MSIX installer logs for more efficient diagnostics.
-File Explorer add-ons now have improved rendering stability, resolving issues with PDF previews, blank thumbnails, and text file crashes during file browsing.
### Color Picker
-Fixed an issue where a resource leak caused hangs or crashes by properly disposing of the Graphics object. Thanks [@dcog989](https://github.com/dcog989)!
- Fixed an issue where Color Picker exited on Backspace keypress by ensuring it only closes when focused and aligning Escape/Backspace behavior. Thanks [@PesBandi](https://github.com/PesBandi)!
- Added support for Oklab and Oklch color formats in Color Picker. Thanks [@lemonyte](https://github.com/lemonyte)!
-Added mouse button actions so you can choose what left, right, or middle click does. Thanks [@PesBandi](https://github.com/PesBandi)!
### Command Not Found
### Crop & Lock
-Updated the WinGet Command Not Found script to only enable the experimental features if they exist.
-Aligned window styling with current Windows theme for a cleaner look. Thanks [@sadirano](https://github.com/sadirano)!
### Command Palette
-Updated bug template to include Command Palette module.
-Fixed an issue where the toast window was not scaled for DPI, causing layout issues under display scaling.
-Fixed an issue where Up/Down keyboard navigation didn't move selection when the caret was at position 0, and added continuous navigation like PT Run v1. Thanks [@davidegiacometti](https://github.com/davidegiacometti)!
-Updated the Time and Date extension code to simplify it and improve clarity.
-Fixed an issue where capitalization in the command causes failure when trying to go to the mouse pointer, resolved by adjusting the command to lowercase.
- Added open URL fallback command for the WebSearch extension, enabling users to directly open URLs in the browser from the Command Palette. Thanks [@htcfreek](https://github.com/htcfreek)!
-Added setting to enable/disable system tray icon in CmdPal and aligned terminology with Windows 11. Thanks [@davidegiacometti](https://github.com/davidegiacometti)!
-Fixed an alias update issue by removing the old alias when a new one is set.
- Resolved GitHub casing conflict by migrating Exts and exts into a new ext directory, ensuring consistent structure across platforms and preventing path fragmentation.
- Fix an issue where the 'Create New Extension' command generated empty file names.
- Added the ability to make the global hotkey a low-level keyboard hook.
- Added support for JUMBO thumbnails, enabling access to high-resolution icons.
- Fixed crashes when CmdPal auto-hid itself while an MSAL dialog was opened, by preventing CmdPal from hiding if it's disabled.
- Added support for immediately selecting search text when a page is loaded.
- Fixed a bug where extension settings pages failed to reload on reopen by updating the settings form when extension settings are saved.
- Fixed an issue where the Command Palette failed to launch from the runner.
- Refactored and ported the PowerToys Run v1 calculator logic into Command Palette, added settings support, and improved fallback behavior.
- Re-added support for list item keyboard shortcuts.
- Enhanced accessibility in Command Palette by adding proper labels, refining animations, improving localization, and fixed a11y related issues.
- Ported custom format support to the Time and Date plugin, reordered and cleaned up settings, improved error messaging, and fixed edge-case crashes for more robust and user-friendly behavior. Thanks [@htcfreek](https://github.com/htcfreek)!
- Added fallback item for system command.
- Fixed a bug in Windows System Command where the key prompt incorrectly displayed "Empty" for the "Open Recycle Bin" action. Thanks [@jironemo](https://github.com/jironemo)!
- Fixed an issue where the 'more commands' list showed commands that shouldn't be visible. Thanks [@davidegiacometti](https://github.com/davidegiacometti)!
- Fixed an issue where the details view in Command Palette displayed an oversized icon and misaligned text, aligning it with Windows Search behavior.
- Fixed a bug where empty screen content and command bar commands were cut off when using long labels, ensuring proper layout and visibility.
- Improved CmdPal’s WinGet integration by fixing version display for installed packages, enabling updates with icons, and migrating the preview winget API to a stable version.
- Fixed a bug where commands for ContentPage didn't update until after exit, by ensuring context menus are fully initialized when they change.
- Added fallback support to the TimeDate extension, enabling direct date/time queries without pre-selecting the command.
- Added import of Common.Dotnet.AotCompatibility.props across multiple CmdPal project files to enhance AOT compilation support.
- Fixed a crash in CmdPal settings caused by a null HotKey when settings.json is missing or lacks a defined hotkey. Thanks [@davidegiacometti](https://github.com/davidegiacometti)!
- Added support for filterable, nested context menus in CmdPal, including a search box to maintain focus behavior.
- Refactored CmdPal classes to improve JSON serialization and introduced new serialization contexts for better performance and maintainability.
- Added support for ahead-of-time (AoT) compilation.
- Added retry mechanism for CmdPal launch.
- Removed some unused files from CmdPal.Common to simplify the codebase and facilitate marking it as AoT-compatible.
- Fixed a bug where a race condition in the update of SearchText caused the cursor in the input box to automatically jump to the end of the line, ensuring SearchText is only updated after it has actually been changed.
- Added support for searching any file in the fallback command.
- Cleaned up AoT-related code to prevent duplicate operations during testing.
- Reduced CmdPal load time by parallelizing extension startup and adding timeouts to prevent misbehaving extensions from blocking others.
- Enhanced UI behavior by dismissing the details pane when the list gets emptied, avoiding inconsistent visual states.
- Added support to unset the fallback command in CmdPal when no matching command is found, ensuring cleaner reload behavior.
- Fixed a leak in the CmdPal extension template by addressing improper ComServer use.
- Prevented CmdPal window from maximizing on title bar double-click to maintain intended window behavior. Thanks [@davidegiacometti](https://github.com/davidegiacometti)!
- Fixed an issue where the Settings UI launched too small by making window dimensions DPI-aware and enforcing minimum width and height using WinUIEx.
- Fixed white flash and one-time animation issues in CmdPal by cloaking the window instead of hiding it.
- Fixed a bug where all extension settings were fetched on startup by lazy-loading extension settings, reducing initialization overhead.
- Added support for protecting CmdPal from crashes on Adaptive Card parse failure.
- Replaced shell:AppsFolder with URI activation in CmdPal to improve reliability.
- Added ability to open CmdPal settings from PowerToys Settings.
- Added ability for CmdPal to observe and dynamically update extension details by tracking property changes on the selected item.
- Bumped the toolkit version used in the CmdPal extension template to 0.2.0.
-Enhanced performance by resolving a regression in page loading.
-Applied consistent hotkey handling across all Command Palette commands for a smoother user experience.
-Improved graceful closing of Command Palette. Thanks [@davidegiacometti](https://github.com/davidegiacometti)!
-Fixed consistency issue for extensions' alias with "Direct" setting and enabled localization for "Direct" and "Indirect" for better user understanding. Thanks [@davidegiacometti](https://github.com/davidegiacometti)!
-Improved visual clarity by styling critical context items correctly.
- Automatically focused the field when only one is present on the content page.
-Improved stability and efficiency when loading file icons in SDK ThumbnailHelper.cs by removing unnecessary operations. Thanks [@OldUser101](https://github.com/OldUser101)!
-Enhanced details view with commands implementation. (See [Extension sample](./src/modules/cmdpal/ext/SamplePagesExtension/Pages/SampleListPageWithDetails.cs))
### Image Resizer
### Command Palette extensions
-Fixed an issue where deleting an Image Resizer preset removed the wrong preset.
-Added "Copy Path" command to *App* search results for convenience. Thanks [@PesBandi](https://github.com/PesBandi)!
- Improved *Calculator* input experience by ignoring leading equal signs. Thanks [@PesBandi](https://github.com/PesBandi)!
- Corrected input handling in the *Calculator* extension to avoid showing errors for input with only leading whitespace.
- Improved *New Extension* wizard by validating names to prevent namespace errors.
- Ensured consistent context items display for the *Run* extension between fallback and top-level results.
- Fixed outdated results in the *Time & Date* extension. Thanks [@htcfreek](https://github.com/htcfreek)!
- Fixed an issue where *Web Search* always opened Microsoft Edge instead of the user's default browser on Windows 11 24H2 and later. Thanks [@RuggMatt](https://github.com/RuggMatt)!
- Improved ordering of *Windows Settings* extension search results from alphabetical to relevance-based for quicker access.
- Added "Restart Windows Explorer" command to the *Windows System Commands* provider for gracefully terminate and relaunch explorer.exe. Thanks [@jiripolasek](https://github.com/jiripolasek)!
### Keyboard Manager
### Command Palette Ahead-of-Time (AOT) readiness
-Fixed an issue where a modifier key, when set without specifying left or right, would get stuck due to incorrect key handling by tracking the pressed keys and sending the correct key accordingly. Thanks [@mantaionut](https://github.com/mantaionut)!
-We’ve made foundational changes to prepare the Command Palette for future Ahead-of-Time (AOT) publishing. This includes replacing the calculator library with ExprTk, improving COM object handling, refining Win32 interop, and correcting trimming behavior—all to ensure compatibility, performance, and reliability under AOT constraints. All first-party extensions are now AOT-compatible. These improvements lay the groundwork for publishing Command Palette as an AOT application in the next release.
- Special thanks to [@Sergio0694](https://github.com/Sergio0694) for guidance on making COM APIs AOT-compatible, [@jtschuster](https://github.com/jtschuster) for fixing COM object handling, [@ArashPartow](https://github.com/ArashPartow) from ExprTk for integration suggestions, and [@tian-lt](https://github.com/tian-lt) from the Windows Calculator team for valuable suggestion throughout the migration journey and review.
- As part of the upcoming release, we’re also enabling AOT compatibility for key dependencies, including markdown rendering, Adaptive Cards, internal logging and telemetry library, and the core Command Palette UX.
### FancyZones
- Fixed DPI-scaling issues to ensure FancyZones Editor displays crisply on high-resolution monitors. Thanks [@HO-COOH](https://github.com/HO-COOH)! This inspired us a broader review across other PowerToys modules, leading to DPI display optimizations in Awake, Color Picker, PowerAccent, and more.
### File Explorer add-ons
- Fixed potential failures in PDF previewer and thumbnail generation, improving reliability when browsing PDF files. Thanks [@mohiuddin-khan-shiam](https://github.com/mohiuddin-khan-shiam)!
- Prevented Monaco Preview Handler crash when opening UTF-8-BOM text files.
### Hosts File Editor
- Added an in-app *“Learn more”* link to warning dialogs for quick guidance. Thanks [@PesBandi](https://github.com/PesBandi)!
### Mouse Without Borders
- Fixed firewall rule so MWB now accepts connections from IPs outside your local subnet.
- Cleaned legacy logs to reduce disk usage and noise.
### Peek
- Updated QOI reader so 3-channel QOI images preview correctly in Peek and File Explorer. Thanks [@mbartlett21](https://github.com/mbartlett21)!
- Added codec detection with a clear warning when a video can’t be previewed, along with a link to the Microsoft Store to download the required codec.
### PowerRename
-Enhanced PowerRename's time formatting capabilities by adding 12-hour time format patterns with AM/PM support. Thanks [@bitmap4](https://github.com/bitmap4)!
-Added support for $YY-$MM-$DD in ModificationTime and AccessTime to enable flexible date-based renaming.
### PowerToys Run
-Added support for custom formats in the "Time and Date" plugin and improved error messages for invalid input formats. Thanks [@htcfreek](https://github.com/htcfreek)!
- Fix two crashes: one for WFT on very early dates and another for calculating the week of the month on very late dates (e.g., 31.12.9999), and reorder UI settings. Thanks [@htcfreek](https://github.com/htcfreek)!
- Fix an issue where capitalization in the command causes failure when trying to go to the mouse pointer, resolved by adjusting the command to lowercase.
- Added version details to plugin error messages for 'Loading error' and 'Init error'. Thanks [@htcfreek](https://github.com/htcfreek)!
- Enhanced result model by adding support for preventing usage-based ordering, giving plugin developers greater control over sorting behavior. Thanks [@CoreyHayward](https://github.com/CoreyHayward) and [@htcfreek](https://github.com/htcfreek)!
### Quick Accent
- Updated the letter mapping in GetDefaultLetterKeyEPO, replacing "ǔ" with "ŭ" for the VK_U key to accurately reflect Esperanto phonetics. Thanks [@OlegKharchevkin](https://github.com/OlegKharchevkin)!
- Fixed an issue where Quick Accent did not work properly when using the on-screen keyboard. Thanks [@davidegiacometti](https://github.com/davidegiacometti)!
-Suppressed error UI for known WPF-related crashes to reduce user confusion, while retaining diagnostic logging for analysis. This targets COMException 0xD0000701 and 0x80263001 caused by temporary DWM unavailability.
### Registry Preview
-Enhanced Registry Preview to support pasting registry keys and values without manually writing the file header, and added a new button for resetting the app. Thanks [@htcfreek](https://github.com/htcfreek)!
-Added "Extended data preview" via magnifier icon and context menuin the Data Grid, enabled easier inspection of complex registry types like REG_BINARY, REG_EXPAND_SZ, and REG_MULTI_SZ, etc. Thanks [@htcfreek](https://github.com/htcfreek)!
- Improved file-saving experience in Registry Preview by aligning with Notepad-like behavior, enhancing user prompts, error handling, and preventing crashes during unsaved or interrupted actions. Thanks [@htcfreek](https://github.com/htcfreek)!
### Settings
-Fix an issue where the Settings app randomly showed a blank icon in the taskbar by deferring icon assignment until the window is activated.
-Added the ability to maximize the "What's New" window for a more comfortable reading experience.
-Added an option to hide or show the PowerToys system tray icon. Thanks [@BLM16](https://github.com/BLM16)!
-Improved settings to show progress while a bug report package is being generated.
### Workspaces
-Fixed bugs where Steam games were not captured or launched correctly by updating window filtering and integrating Steam URL protocol handling.
-Stored Workspaces icons in user AppData to ensure profile portability and prevent loss during temporary folder cleanup.
- Enabled capture and launch of PWAs on non-default Edge or Chrome profiles, ensuring consistent behavior during creation and execution.
### Documentation
- Added QuickNotes to the third-party plugins documentation for PowerToys Run. Thanks [@ruslanlap](https://github.com/ruslanlap)!
-Added Weather and Pomodoro plugins to the PowerToys Run third-party plugin documentation. Thanks [@ruslanlap](https://github.com/ruslanlap)!
- Added the Linear plugin to PowerToys Run's third-party plugin documentation. Thanks [@vednig](https://github.com/vednig)!
- Fixed formatting issues in documentation files and updated contributor and team member information. Thanks [@DanielEScherzer](https://github.com/DanielEScherzer) and [@RokyZevon](https://github.com/RokyZevon)!
- Added SpeedTest and Dictionary Definition to the third-party plugins documentation for PowerToys Run. Thanks [@ruslanlap](https://github.com/ruslanlap)!
-Corrected sample links and typo in Command Palette documentation. Thanks [@daverayment](https://github.com/daverayment) and [@roycewilliams](https://github.com/roycewilliams)!
### Development
- Updated GitHub Action to install .NET 9 for MSStore release support.
- Updated version placeholder in bug_report.yml to prevent incorrect v0.70.0 versioning in issue reports.
-Updated GitHub Action to upgrade actions/setup-dotnet from version 3 to version 4 for MSStore release.
-Added securityContext to WinGet configuration files, allowing invocation from user context and prompting a single UAC for elevated resources in a separate process. Thanks [@mdanish-kh](https://github.com/mdanish-kh)!
-Changed log file extensions from .txt to .log to support proper file associations and tooling compatibility,and added logs for Workspace. Thanks [@benwa](https://github.com/benwa)!
-Upgraded testing framework dependencies and aligned package versions across components.
-Upgraded dependencies to fix vulnerabilities.
- Enhanced repository security by pinning GitHub Actions and Docker tags to immutable full-length commits and integrating automated dependency vulnerability scanning via Dependency Review Workflow. Thanks [@Nick2bad4u](https://github.com/Nick2bad4u)!
-Upgraded Boost dependencies to a newer version.
- Upgraded toolkit to the latest version, suppressed AoT-related warnings.
-Fixed an issue where missing signing for newly added files caused build failures.
-Update release pipeline to prevent publishing private symbols for 100 years.
- Introduced fuzzing for PowerRename to improve reliability and added setup guidance for extending fuzzing to other C++ modules.
-Added centralized pre-creation of generated folders for all .csproj projects to prevent build failures.
-Updated WinAppSDK to the latest 1.7 version.
- Upgraded Boost dependencies to the latest version for the PowerRename Fuzzing project.
- Updated the ADO area path in tsa.json to resolve TSA pipeline errors caused by a deprecated path.
- Initiated AoT support for CmdPal with foundational work in progress.
### Tool/General
- Updated .NET libraries to 9.0.6 for performance and security. Thanks [@snickler](https://github.com/snickler)!
- Updated WinAppSDK to 1.7.2 for better stability and Windows support.
-Introduced a one-step local build script that generates a signed installer, enhancing developer productivity.
-Generated portable PDBs so cross-platform debuggers can read symbol files, improving debugging experience in VSCode and other tools.
-Simplified WinGet configuration files by using the [Microsoft.Windows.Settings](https://www.powershellgallery.com/packages/Microsoft.Windows.Settings) module to enable Developer Mode. Thanks [@mdanish-kh](https://github.com/mdanish-kh)!
-Adjusted build scripts for the latest Az.Accounts module to keep CI green.
-Streamlined release pipeline by removing hard-coded telemetry version numbers, and unified Command Palette versioning with Windows Terminal's versioning method for consistent updates.
- Enhanced the build validation step to show detailed differences between NOTICE.md and actual package dependencies and versions.
-Improved spell-checking accuracy across the repo. Thanks [@rovercoder](https://github.com/rovercoder)!
- Upgraded CI to TouchdownBuild v5 for faster pipelines.
-Added context comments to *Resources.resw* to help translators.
-Expanded fuzz testing coverage to include FancyZones.
- Integrated all unit tests into the CI pipeline, increasing from ~3,000 to ~5,000 tests.
-Enabled daily UI test automation on the main branch, now covering over 370 UI tests for end-to-end validation.
-Newly added unit tests for WorkspacesLib to improve reliability and maintainability.
- Added support for automating bug report creation by generating a pre-filled GitHub issue URL with system and diagnostic information. Thanks [@donlaci](https://github.com/donlaci)!
- Added scripts to locally build the installer, ensuring the CmdPal can also be launched in a local environment.
- Removed export PFX logic to eliminate hardcoded password usage and resolve PSScriptAnalyzer security warning.
- Added PowerShell script and CI integration to enforce consistent use of Common.Dotnet.CsWinRT.props across all C# projects under the src folder.
### What is being planned for version 0.92
### General
For [v0.92][github-next-release-work], we'll work on the items below:
- Updated bug report compression library (cziplib 0.3.3) for faster and more reliable package creation. Thanks [@Chubercik](https://github.com/Chubercik)!
- Included App Installer (“AppX Deployment Server”) event logs in bug reports for more thorough diagnostics.
### What is being planned for version 0.93
For [v0.93][github-next-release-work], we'll work on the items below:
## ⚙️ [Test run in the cloud](https://eng.ms/docs/cloud-ai-platform/azure-edge-platform-aep/aep-security/epsf-edge-and-platform-security-fundamentals/the-onefuzz-service/onefuzz/faq/notwindows/walkthrough)
To submit a job to the cloud you can run with this command:
You want to run with --do-not-file-bugs because if there is an issue with running the parser in the cloud (which is very possible), you don't want bugs to be created if there is an issue. The --duration task is the number of hours you want the task to run. I recommend just running for 1 hour to make sure things work initially. If you don't specify this parameter, it will default to 48 hours. You can find more about submitting a test job here.
OneFuzz will send you an email when the job has started.
Monaco is the text editor that powers Visual Studio Code. In PowerToys, Monaco is integrated as a component to provide advanced text editing capabilities with features like syntax highlighting, line numbering, and intelligent code editing.
## Where Monaco is Used in PowerToys
Monaco is primarily used in:
- Registry Preview module - For editing registry files
- File Preview handlers - For syntax highlighting when previewing code files
- Peek module - For preview a file
## Technical Implementation
Monaco is embedded into PowerToys' WinUI 3 applications using WebView2. This integration allows PowerToys to leverage Monaco's web-based capabilities within desktop applications.
### Directory Structure
The Monaco editor files are located in the relevant module directories. For example, in Registry Preview, Monaco files are bundled with the application resources.
## Versioning and Updates
### Current Version
The current Monaco version can be found in the `loader.js` file, specifically in the variable named `versionMonaco`.
### Update Process
Updating Monaco requires several steps:
1. Download the latest version of Monaco
2. Replace/override the main folder with the new version
3. Generate the new Monaco language JSON file
4. Override the existing JSON file
For detailed step-by-step instructions, see the [FilePreviewCommon documentation](FilePreviewCommon.md#update-monaco-editor).
#### Estimated Time for Update
The Monaco update process typically takes approximately 30 minutes.
#### Reference PRs
When updating Monaco, you can refer to previous Monaco update PRs as examples, as they mostly involve copy-pasting the Monaco source code with minor adjustments.
## Customizing Monaco
### Adding New Language Definitions
Monaco can be customized to support new language definitions for syntax highlighting:
1. Identify the language you want to add
2. Create or modify the appropriate language definition files
3. Update the Monaco configuration to recognize the new language
For detailed instructions on adding language definitions, see the [FilePreviewCommon documentation](FilePreviewCommon.md#add-a-new-language-definition).
### Adding File Extensions to Existing Languages
To make Monaco handle additional file extensions using existing language definitions:
1. Locate the language mapping configuration
2. Add the new file extension to the appropriate language entry
3. Update the file extension registry
For detailed instructions on adding file extensions, see the [FilePreviewCommon documentation](FilePreviewCommon.md#add-a-new-file-extension-to-an-existing-language).
Example: If Monaco processes TXT files and you want it to preview LOG files the same way, you can add LOG extensions to the TXT language definition.
## Installer Handling
Monaco source files are managed via a script (`Generate-Monaco-wxs.ps1`) that:
1. Automatically generates the installer manifest to include all Monaco files
2. Avoids manually listing all Monaco files in the installer configuration
This approach simplifies maintenance and updates of the Monaco editor within PowerToys.
Each PowerToys utility is defined by a module interface (DLL) that provides a standardized way for the PowerToys Runner to interact with it. The module interface defines:
- Structure for hotkeys
- Name and key for the utility
- Configuration management
- Enable/disable functionality
- Telemetry settings
- Group Policy Object (GPO) configuration
### Types of Modules
1.**Simple Modules** (like Mouse Pointer Crosshairs, Find My Mouse)
- Entirely contained in the module interface
- No external application
- Example: Mouse Pointer Crosshairs implements the module interface directly
2.**External Application Launchers** (like Color Picker)
- Start a separate application (e.g., WPF application in C#)
- Handle events when hotkeys are pressed
- Communication via named pipes or other IPC mechanisms
3.**Context Handler Modules** (like Power Rename)
- Shell extensions for File Explorer
- Add right-click context menu entries
- Windows 11 context menu integration through MSIX
4.**Registry-based Modules** (like Power Preview)
- Register preview handlers and thumbnail providers
- Modify registry keys during enable/disable operations
## Common Dependencies and Libraries
- SPD logs for C++ (centralized logging system)
- CPP Win RT (used by most utilities)
- Common utilities in `common` folder for reuse across modules
- Interop library for C++/C# communication (converted to C++ Win RT)
- Common.UI library has WPF and WinForms dependencies
## Resource Management
- For C++ applications and module interfaces:
- Resource files (.resx) need to be converted to .rc
- Use conversion tools before building
- Different resource approaches:
- WPF applications use .resx files
- WinUI 3 apps use .resw files
- PRI file naming requirements:
- Need to override default names to avoid conflicts during flattening
## Implementation details
### [`Runner`](runner.md)
The PowerToys Runner contains the project for the PowerToys.exe executable.
It's responsible for:
- Loading the individual PowerToys modules.
- Passing registered events to the PowerToys.
- Showing a system tray icon to manage the PowerToys.
- Bridging between the PowerToys modules and the Settings editor.
### [`Interface`](../modules/interface.md)
The definition of the interface used by the [`runner`](/src/runner) to manage the PowerToys. All PowerToys must implement this interface.
### [`Common`](../common.md)
The common lib, as the name suggests, contains code shared by multiple PowerToys components and modules, e.g. [json parsing](/src/common/utils/json.h) and [IPC primitives](/src/common/interop/two_way_pipe_message_ipc.h).
### [`Settings`](settings/readme.md)
Settings v2 is our current settings implementation. Please head over to the dev docs that describe the current settings system.
- Logs in Bug Reports are useful for troubleshooting installation issues
### Building PowerToys Locally
#### Prerequisites for building the MSI installer
1. Install the [WiX Toolset Visual Studio 2022 Extension](https://marketplace.visualstudio.com/items?itemName=WixToolset.WixToolsetVisualStudio2022Extension).
1. Install the [WiX Toolset build tools](https://github.com/wixtoolset/wix3/releases/tag/wix3141rtm). (installer [direct link](https://github.com/wixtoolset/wix3/releases/download/wix3141rtm/wix314.exe))
1. Download [WiX binaries](https://github.com/wixtoolset/wix3/releases/download/wix3141rtm/wix314-binaries.zip) and extract `wix.targets` to `C:\Program Files (x86)\WiX Toolset v3.14`.
#### Building prerequisite projects
##### From the command line
1. From the start menu, open a `Developer Command Prompt for VS 2022`
- The Runner and Settings UI communicate through Windows Named Pipes
- A two-way pipe (TwoWayPipeMessageIPC) is established between processes
- JSON messages are sent through this pipe to control UI behavior
- The Settings UI initializes the pipe connection on startup:
```csharp
ipcmanager = new TwoWayPipeMessageIPCManaged(cmdArgs[(int)Arguments.SettingsPipeName],
cmdArgs[(int)Arguments.PTPipeName],
(string message) => {
if (IPCMessageReceivedCallback != null && message.Length > 0) {
IPCMessageReceivedCallback(message);
}
});
```
### Settings UI Message Processing
The Settings UI processes incoming IPC messages through a callback chain:
1. Messages from the Runner are received through the IPC callback
2. Messages are parsed as JSON objects
3. Registered handlers in `ShellPage.ShellHandler.IPCResponseHandleList` process the messages
4. The `ReceiveMessage` method in `ShellPage` interprets commands:
- For flyout display: `"ShowYourself": "flyout"`
- For main window: `"ShowYourself": "Dashboard"` or other page names
When showing the flyout, the tray icon can also send position coordinates to place the flyout near the tray icon:
```json
{
"ShowYourself": "flyout",
"x_position": 1234,
"y_position": 567
}
```
The flyout window is then activated and brought to the foreground using native Windows APIs to ensure visibility.
### Tray Icon Menu
- Menus are defined in `.RC` files (Resource files)
- `base.h` defines IDs
- `resources.resx` contains localized strings
- The tray icon window proc handles showing the popup menu
## Centralized Keyboard Hook
- Located in "centralized_keyboard_hook.cpp"
- Handles hotkeys for multiple modules to prevent performance issues
- Contains optimizations to exit early when possible:
- Ignores keystrokes generated by PowerToys itself
- Ignores when no keys are actually pressed
- Uses metadata to avoid re-processing modified inputs
- Performance consideration: handler must run very fast as it's called on every keystroke
## Module Loading Process
1. Scan module directory for DLLs
2. Create the module interface object for each module
3. Load settings for each module
4. Initialize each module
5. Check GPO policies to determine which modules can start
6. Start enabled modules that aren't disabled by policy
## Finding and Messaging the Tray Icon
The tray icon class is used when sending messages to the runner. For example, to close the runner:
```cpp
// Find the window with the PowerToys tray icon class and send it a close message
WM_CLOSE
```
## Key Files and Their Purposes
#### [`main.cpp`](/src/runner/main.cpp)
Contains the executable starting point, initialization code and the list of known PowerToys. All singletons are also initialized here at the start. Loads all the powertoys by scanning the `./modules` folder and `enable()`s those marked as enabled in `%LOCALAPPDATA%\Microsoft\PowerToys\settings.json` config. Then it runs [a message loop](https://learn.microsoft.com/windows/win32/winmsg/using-messages-and-message-queues) for the tray UI. Note that this message loop also [handles lowlevel_keyboard_hook events](https://github.com/microsoft/PowerToys/blob/1760af50c8803588cb575167baae0439af38a9c1/src/runner/lowlevel_keyboard_event.cpp#L24).
#### [`powertoy_module.h`](/src/runner/powertoy_module.h) and [`powertoy_module.cpp`](/src/runner/powertoy_module.cpp)
Contains code for initializing and managing the PowerToy modules. `PowertoyModule` is a RAII-style holder for the `PowertoyModuleIface` pointer, which we got by [invoking module DLL's `powertoy_create` function](https://github.com/microsoft/PowerToys/blob/1760af50c8803588cb575167baae0439af38a9c1/src/runner/powertoy_module.cpp#L13-L24).
#### [`tray_icon.cpp`](/src/runner/tray_icon.cpp)
Contains code for managing the PowerToys tray icon and its menu commands. Note that `dispatch_run_on_main_ui_thread` is used to
transfer received json message from the [Settings window](/doc/devdocs/settings.md) to the main thread, since we're communicating with it from [a dedicated thread](https://github.com/microsoft/PowerToys/blob/7357e40d3f54de51176efe54fda6d57028837b8c/src/runner/settings_window.cpp#L267-L271).
Contains code for starting the PowerToys settings window and communicating with it. Settings window is a separate process, so we're using [Windows pipes](https://learn.microsoft.com/windows/win32/ipc/pipes) as a transport for json messages.
PowerToys settings can be controlled and enforced via Group Policy. This document describes how Group Policy integration is implemented in the settings system.
## Overview
Group Policy settings for PowerToys allow administrators to:
- Enable or disable PowerToys entirely
- Control which modules are available
- Configure specific settings for individual modules
- Enforce settings across an organization
## Implementation Details
When a setting is controlled by Group Policy:
1. The UI shows the setting as locked (disabled)
2. The module checks GPO settings before applying user settings
3. GPO settings take precedence over user settings
## Group Policy Settings Detection
The settings UI checks for Group Policy settings during initialization:
```csharp
// Example code for checking if a setting is controlled by GPO
When a setting is managed by Group Policy, the UI indicates this to the user:
- Controls are disabled (grayed out)
- A tooltip indicates the setting is managed by policy
- The actual policy value is displayed
## Testing Group Policy Settings
To test Group Policy integration:
1. Create a test GPO using the PowerToys ADMX template
2. Apply settings in the Group Policy Editor
3. Verify that the settings UI correctly reflects the policy settings
4. Verify that the modules honor the policy settings
## GPO Settings vs. User Settings
The precedence order for settings is:
1. Group Policy settings (highest priority)
2. User settings (lower priority)
3. Default settings (lowest priority)
When a setting is controlled by Group Policy, attempts to modify it through the settings UI or programmatically will not persist, as the policy value will always take precedence.
For more information on PowerToys Group Policy implementation, see the [GPO Implementation](/doc/devdocs/processes/gpo.md) documentation.
PowerToys provides a comprehensive settings system that allows users to configure various aspects of the application and its modules. This document provides an overview of the settings system architecture and links to more detailed documentation.
This document describes how settings are implemented in PowerToys modules, including code examples for C++ and C# modules, and details on debugging settings issues.
## C++ Settings Implementation
For C++ modules, the settings system is implemented in the following files:
-`settings_objects.h` and `settings_objects.cpp`: Define the basic settings objects
-`settings_helpers.h` and `settings_helpers.cpp`: Helper functions for reading/writing settings
-`settings_manager.h` and `settings_manager.cpp`: Main interface for managing settings
1. The settings UI serializes the settings to JSON
2. The JSON is sent to the PowerToys runner via IPC
3. The runner calls the `set_config` function on the appropriate module
4. The module parses the JSON and applies the new settings
## Debugging Settings
To debug settings issues:
1. Check the settings files in `%LOCALAPPDATA%\Microsoft\PowerToys\`
2. Ensure JSON is well-formed
3. Monitor IPC communication between settings UI and runner using debugger breakpoints at key points:
- In the Settings UI when sending configuration changes
- In the Runner when receiving and dispatching changes
- In the Module when applying changes
4. Look for log messages related to settings changes in the PowerToys logs
### Common Issues
- **Settings not saving**: Check file permissions or conflicts with other processes accessing the file
- **Settings not applied**: Verify IPC communication is working and the module is properly handling the configuration
- **Incorrect settings values**: Check JSON parsing and type conversion in the module code
## Adding a New Module with Settings
Adding a new module with settings requires changes across multiple projects. Here's a step-by-step guide with references to real implementation examples:
### 1. Settings UI Library (Data Models)
Define the data models for your module's settings in the Settings UI Library project. These data models will be serialized to JSON configuration files stored in `%LOCALAPPDATA%\Microsoft\PowerToys\`.
The ShellPage.xaml is the entry point for the PowerToys settings, providing a navigation view of all modules. Add a navigation item for your new module.
This document covers techniques and tools for debugging PowerToys.
## Pre-Debugging Setup
Before you can start debugging PowerToys, you need to set up your development environment:
1. Fork the repository and clone it to your machine
2. Navigate to the repository root directory
3. Run `git submodule update --init --recursive` to initialize all submodules
4. Change directory to `.config` and run `winget configure .\configuration.vsEnterprise.winget` (pick the configuration file that matches your Visual Studio distribution)
### Optional: Building Outside Visual Studio
You can build the entire solution from the command line, which is sometimes faster than building within Visual Studio:
1. Open Developer Command Prompt for VS 2022
2. Navigate to the repository root directory
3. Run the following command(don't forget to set the correct platform):
4. This process should complete in approximately 13-14 minutes for a full build
## Debugging Techniques
### Visual Studio Debugging
To debug the PowerToys application in Visual Studio, set the `runner` project as your start-up project, then start the debugger.
Some PowerToys modules must be run with the highest permission level if the current user is a member of the Administrators group. The highest permission level is required to be able to perform some actions when an elevated application (e.g. Task Manager) is in the foreground or is the target of an action. Without elevated privileges some PowerToys modules will still work but with some limitations:
- The `FancyZones` module will not be able to move an elevated window to a zone.
- The `Shortcut Guide` module will not appear if the foreground window belongs to an elevated application.
Therefore, it is recommended to run Visual Studio with elevated privileges when debugging these scenarios. If you want to avoid running Visual Studio with elevated privileges and don't mind the limitations described above, you can do the following: open the `runner` project properties and navigate to the `Linker -> Manifest File` settings, edit the `UAC Execution Level` property and change it from `highestAvailable (level='highestAvailable')` to `asInvoker (/level='asInvoker').
### Shell Process Debugging Tool
The Shell Process Debugging Tool is a Visual Studio extension that helps debug multiple processes, which is especially useful for PowerToys modules started by the runner.
#### Debugging Setup Process
1. Install ["Debug Child Processes"](https://marketplace.visualstudio.com/items?itemName=vsdbgplat.MicrosoftChildProcessDebuggingPowerTool2022) Visual Studio extension
2. Configure which processes to debug and what debugger to use for each
3. Start PowerToys from Visual Studio
4. The extension will automatically attach to specified child processes when launched
#### Debugging Color Picker Example
1. Set breakpoints in both ColorPicker and its module interface
2. Use Shell Process Debugging to attach to ColorPickerUI.exe
3. Debug .NET and native code together
4. Runner needs to be running to properly test activation
#### Debugging DLL Main/Module Interface
- Breakpoints in DLL code will be hit when loaded by runner
- No special setup needed as DLL is loaded into runner process
#### Debugging Short-Lived Processes
- For processes with short lifetimes (like in Workspaces)
- List all processes explicitly in debugging configuration
- Set correct debugger type (.NET debugger for C# code)
### Finding Registered Events
1. Run WinObj tool from SysInternals as administrator
2. Search for event name
3. Shows handles to the event (typically runner and module)
### Common Debugging Usage Patterns
#### Debugging with Bug Report
1. Check module-specific logs for exceptions/crashes
2. Copy user's settings to your AppData to reproduce their configuration
3. Check Event Viewer XML files if logs don't show crashes
4. Compare installation_folder_structure.txt to detect corrupted installations
5. Check installer logs for installation-related issues
6. Look at Windows version and language settings for patterns across users
1. [Localization on the pipeline (CDPX)](#localization-on-the-pipeline-cdpx)
1. [UWP Special case](#uwp-special-case)
2. [Enabling localization on a new project](#enabling-localization-on-a-new-project)
1. [C++](#c)
2. [C#](#c-1)
3. [UWP](#uwp)
3. [Lcl Files](#lcl-files)
4. [Possible Issues in localization PRs (LEGO)](#possible-issues-in-localization-prs-lego)
5. [Enabling localized MSI for a new project](#enabling-localized-msi-for-a-new-project)
## Localization on the pipeline (CDPX)
[The localization step](https://github.com/microsoft/PowerToys/blob/86d77103e9c69686c297490acb04775d43ef8b76/.pipelines/pipeline.user.windows.yml#L45-L52) is run on the pipeline before the solution is built. This step runs the [build-localization](https://github.com/microsoft/PowerToys/blob/main/.pipelines/build-localization.cmd) script, which generates resx files for all the projects with localization enabled using the `Localization.XLoc` package.
The [`Localization.XLoc`](https://github.com/microsoft/PowerToys/blob/86d77103e9c69686c297490acb04775d43ef8b76/.pipelines/build-localization.cmd#L24-L25) tool is run on the repo root, and it checks for all occurrences of `LocProject.json`. Each localized project has a `LocProject.json` file in the project root, which contains the location of the English resx file, list of languages for localization, and the output path where the localized resx files are to be copied to. In addition to this, some other parameters can be set, such as whether the language ID should be added as a folder in the file path or in the file name. When the CDPX pipeline is run, the localization team is notified of changes in the English resx files. For each project with localization enabled, a `loc` folder (see [this](https://github.com/microsoft/PowerToys/tree/main/src/modules/launcher/Microsoft.Launcher/loc) for example) is created in the same directory as the `LocProject.json` file. The folder contains language specific folders which in turn have a nested folder path equivalent to `OutputPath` in the `LocProject.json`. Each of these folders contain one `lcl` file. The `lcl` files contain the English resources along with their translation for that language. These are described in more detail in the [Lcl files section](#lcl-files). Once the `.resx` files are generated, they will be used during the `Build PowerToys` step for localized versions of the modules.
Since the localization script requires certain nuget packages, the [`restore-localization`](https://github.com/microsoft/PowerToys/blob/main/.pipelines/restore-localization.cmd) script is run before running `build-localization` to install all the required packages. This script must [run in the `restore` step](https://github.com/microsoft/PowerToys/blob/86d77103e9c69686c297490acb04775d43ef8b76/.pipelines/pipeline.user.windows.yml#L37-L39) of pipeline because [the host is network isolated](https://onebranch.visualstudio.com/Pipeline/_wiki/wikis/Pipeline.wiki/2066/Consuming-Packages-in-a-CDPx-Pipeline?anchor=overview) at the `build` step. The [Toolset package source](https://github.com/microsoft/PowerToys/blob/86d77103e9c69686c297490acb04775d43ef8b76/.pipelines/pipeline.user.windows.yml#L23) is used for this.
The process and variables that can be tweaked on the pipeline are described in more detail on [onebranch (account required) under Localization](https://onebranch.visualstudio.com/Pipeline/_wiki/wikis/Pipeline.wiki/290/Localization).
The localized resource dlls for C# projects are added to the MSI only for build on the pipeline. This is done by checking if the [`IsPipeline` variable is defined](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/installer/PowerToysSetup/Product.wxs#L804-L805), which gets defined before [building the installer on the pipeline](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/.pipelines/build-installer.cmd#L4). This is done because the localized resx files are only present on the pipeline, and not having this check would result in the installer project failing to build locally.
## Enabling localization on a new project
To enable localization on a new project, the first step is to create a file `LocProject.json` in the project root.
For example, for a project in the folder `src\path` where the resx file is present in `resources\Resources.resx`, the LocProject.json file will contain the following:
The rest of the steps depend on the project type and are covered in the sections below. The steps to add the localized files to the MSI can be found in [Enabling localized MSI for a new project](#Enabling-localized-MSI-for-a-new-project).
### C++
C++ projects do not support `resx` files, and instead use `rc` files along with `resource.h` files. The CDPX pipeline however doesn't support localizing `rc` files and the other alternative they support is directly translating the resources from the binary which makes it harder to maintain resources. To avoid this, a custom script has been added which expects a resx file and converts the entries to an rc file with a string table and adds resource declarations to a resource.h file so that the resources can be compiled with the C++ project.
If you already have a .rc file, copy the string table to a separate txt file and run the [convert-stringtable-to-resx.ps1](https://github.com/microsoft/PowerToys/blob/main/tools/build/convert-stringtable-to-resx.ps1) script on it. This script is not very robust to input, and requires the data in a specific format, where `IDS_ResName L"ResourceValue"` and any number of spaces can be present in between. The script converts this file to the format expected by [`resgen`](https://learn.microsoft.com/dotnet/framework/tools/resgen-exe-resource-file-generator#Convert), which will convert it to resx. The resource names are changed from all uppercase to title case, and the `IDS_` prefix is removed. Escape characters might have to be manually replaced, for example .rc files would have escaped double quotes as `""`, so this should be replaced with just `"` before converting to the resx files.
After generating the resx file, rename the existing rc and h files to ProjName.base.rc and resource.base.h. In the rc file remove the string table which is to be localized and in the .h file remove all `#define`s corresponding to localized resources. In the vcxproj of the C++ project, add the following build event:
This event runs a script which generates a resource.h and ProjName.rc in the `Generated Files` folder using the strings in all the resx files along with the existing information in resource.base.h and ProjName.base.rc. The script is [convert-resx-to-rc.ps1](https://github.com/microsoft/PowerToys/blob/main/tools/build/convert-resx-to-rc.ps1). The script uses [`resgen`](https://learn.microsoft.com/dotnet/framework/tools/resgen-exe-resource-file-generator#Convert) to convert the resx file to a string table expected in the .rc file format. When the resources are added to the rc file the `IDS_` prefix is added and resource names are in upper case (as it was originally). Any occurrences of `"` in the string resource is escaped as `""` to prevent build errors. The string tables are added to the rc file in the following format:
Since there is no API to identify the `AFX_TARG_*`, `LANG_*` or `SUBLANG_*` values from each langId from the pipeline, these are hardcoded in the script (for each language) as done in [lines 50-77 of `convert-resx-to-rc.ps1`](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/tools/build/convert-resx-to-rc.ps1#L50-L77). **If any other languages are added in the future, this script will have to be updated.** In order to determine what are the language codes, you can open the rc file in Resource View, right click the string table and press `Insert Copy` and choose the corresponding language. This autogenerates the required code and can be used to figure out the language codes. The files also add the resource declarations to a resource.h file, starting from 101 by default(this can be changed by an optional argument). Since the output files will be generated in `Generated Files`, any includes in these two files will require an additional `..\` and wherever resource.h is used, it will have to be included as `Generated Files\resource.h`. While adding `resource.base.h` and `ProjName.base.rc` to the vcxproj, these should be modified to not participate in the build to avoid build errors:
```
<None Include="Resources.resx" />
```
Some rc/resource.h files might be used in multiple projects (for example, KBM). To ensure the projects build for these cases, the build event can be added to the entire directory so that the rc files are generated before any project is built. See [Directory.Build.targets](https://github.com/microsoft/PowerToys/blob/main/src/modules/keyboardmanager/Directory.Build.targets) for an example.
Check [this PR](https://github.com/microsoft/PowerToys/pull/6104) for an example for making these changes for a C++ project.
### C#
Since C# projects natively support `resx` files, the only step required here is to include all the resx files in the build. For .NET Core projects this is done automatically and the .csproj does not need to be modified. For other projects, the following line needs to be added:
**Note:** Building with localized resources may cause a build warning `Referenced assembly 'mscorlib.dll' targets a different processor` which is a VS bug. More details can be found in [PowerToys issue #7269](https://github.com/microsoft/PowerToys/issues/7269).
**Note:** If a project needs to be migrated from XAML resources to resx, the easiest way to convert the resources would be to change to format to `=` separates resources by either manually (by Ctrl+H on a text editor), or by a script, and then running [`resgen`](https://learn.microsoft.com/dotnet/framework/tools/resgen-exe-resource-file-generator#Convert) on `Developer Command Prompt for VS` to convert it to resx format.
<system:String x:Key="wox_plugin_calculator_plugin_description">Allows to do mathematical calculations.(Try 5*3-2 in Wox)</system:String>
<system:String x:Key="wox_plugin_calculator_not_a_number">Not a number (NaN)</system:String>
```
to
```
wox_plugin_calculator_plugin_name=Calculator
wox_plugin_calculator_plugin_description=Allows to do mathematical calculations.(Try 5*3-2 in Wox)
wox_plugin_calculator_not_a_number=Not a number (NaN)
```
After adding the resx file to the project along with the resource generator, references to the strings will have to be replaced with `Properties.Resources.resName` rather than the custom APIs. Check [this PR](https://github.com/microsoft/PowerToys/pull/6165) for an example of the changes required.
### UWP
UWP projects expect `resw` files rather than `resx` (the format is almost the same). Unlike other C# projects, the files are expected in the format `fullLangId\Resources.resw`. To include these files in the build, replace the following line in the csproj:
The `<Tgt>` element would not be present in the initial commits of the lcl files, as only the English version of the string would be present.
**Note:** The CDPX Localization system has a fail-safe check on the lcl files, where if the English string value which is present inside `<Val><![CDATA[*]]></Val>` does not match the value present in the English Resources.resx file then the translated value will not be copied to the localized resx file. This is present so that obsolete translations would not be loaded when the English resource has changed, and the English string will be used rather than the obsolete translation.
## Possible Issues in localization PRs (LEGO)
Since the LEGO PRs update some of the strings in LCL files at a time, there can be multiple PRs which modify the same files, leading to merge conflicts. In most cases this would show up on GitHub as a merge conflict, but sometimes a bad git merge may occur, and the file could end up with incorrect formatting, such as two `<Tgt>` elements for a single resource. These can be fixed by ensuring the elements follow the format described in [this section](#lcl-files). To catch such errors, the build farm should be run for every LEGO PR and if any error occurs in the localization step, we should check the corresponding resx/lcl files for conflicts.
## Enabling localized MSI for a new project
For C++ and UWP projects no additional files are generated with localization that need to be added to the MSI. For C++ projects all the resources are added to the dll/exe, while for UWP projects they are added to the `resources.pri` file (which is present even for an unlocalized project). To verify if the localized resources are added to the `resources.pri` file the following steps can be done:
- Open `Developer Command Prompt for VS`
- After navigating to the folder containing the pri file, run the following command:
makepri.exe dump /if .\resources.pri
- Check the contents of the `resources.pri.xml` file that is generated from the command. The last section of the file will contain the resources with the strings in all the languages:
For C# projects, satellite dlls are generated when the project is built. For a project named `ProjName`, files are created in the format `langId\ProjName.resources.dll` where `langId` is in the same format as the lcl files. The satellite dlls need to be included with the MSI, but they must be added only if the solution is built from the build farm, as the localized resx files will not be present on local machines (and that could cause local builds of the installer to fail).
This can be done by adding the directory name of the project to [Product.wxs near line 806](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/installer/PowerToysSetup/Product.wxs#L806) and a resource component for the project can be created in [Product.wxs near lines 845-847](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/installer/PowerToysSetup/Product.wxs#L845-L847) in this format:
We should also ensure the new dlls are signed by the pipeline. Currently all dlls of the form [`*.resources.dll` are signed](https://github.com/microsoft/PowerToys/blob/f92bd6ffd38014c228544bb8d68d0937ce4c2b6d/.pipelines/pipeline.user.windows.yml#L68).
**Note:** The resource dlls should be added to the MSI project only after the initial commit with the lcl files has been done by the Localization team. Otherwise the pipeline will fail as there wouldn't be any resx files to generate the dlls.
## Working With Strings
In order to support localization **YOU SHOULD NOT** have hardcoded UI display strings in your code. Instead, use resource files to consume strings.
### For CPP
Use [`StringTable` resource][String Table] to store the strings and resource header file(`resource.h`) to store Id's linked to the UI display string. Add the strings with Id's referenced from the header file to the resource-definition script file. You can use [Visual Studio Resource Editor][VS Resource Editor] to create and manage resource files.
-`resource.h`:
XXX must be a unique int in the list (mostly the int ID of the last string id plus one):
```cpp
#define IDS_MODULE_DISPLAYNAME XXX
```
-`StringTable` in resource-definition script file `validmodulename.rc`:
```
STRINGTABLE
BEGIN
IDS_MODULE_DISPLAYNAME L"Module Name"
END
```
- Use the `GET_RESOURCE_STRING(UINT resource_id)` method to consume strings in your code.
Use [XML resource file(.resx)][Resx Files] to store the UI display strings and [`Resource Manager`][Resource Manager] to consume those strings in the code. You can use [Visual Studio][Resx Files VS] to create and manage XML resources files.
In case of Visual Studio is used to create the resource file. Simply use the `Resources` class in auto-generated `Resources.Designer.cs` file to access the strings which encapsulate the [`Resource Manager`][Resource Manager] logic.
PowerToys has several types of logging mechanisms:
1. Text file logs (application writes logs to files)
2. Telemetry/diagnostic data (sent to Microsoft servers)
3. Event Viewer logs (used by some utilities like Mouse Without Borders)
4. Watson reports (crash reports sent to Microsoft)
## Log File Locations
### Regular Logs
- Located at: `%LOCALAPPDATA%\Microsoft\PowerToys\Logs`
- Organized by utility and sometimes by version
- Examples: PowerToys Run logs, module interface logs
- C# and C++ components both write logs to these locations
### Low-Privilege Logs
- Some components (like preview handlers and thumbnail providers) are started by Explorer and have low privileges
- These components write logs to: `%USERPROFILE%/AppData/LocalLow/Microsoft/PowerToys`
- Example: Monaco preview handler logs
### Module Logs
- Logs always stored in user's AppData regardless of installation type
- Each module creates its own log
- Even with machine-wide installation, logs are per-user
- Different users can have different logs even with a machine-wide installation
## Log Implementation
### C++ Logging
In C++ projects we use the awesome [spdlog](https://github.com/gabime/spdlog) library for logging as a git submodule under the `deps` directory. To use it in your project, just include [spdlog.props](/deps/spdlog.props) in a .vcxproj like this:
```xml
<ImportProject="..\..\..\deps\spdlog.props"/>
```
It'll add the required include dirs and link the library binary itself.
- Projects need to include the logging project as a dependency
- Uses a git submodule for the actual logging library
- Logs are initialized in the main file:
```cpp
init_logger();
```
- After initialization, any file can use the logger
- Logger settings contain constants like log file locations
### C# Logging
For C# projects there is a static logger class in Managed Common called `Logger`.
To use it, add a project reference to `ManagedCommon` and add the following line of code to all the files using the logger:
```Csharp
using ManagedCommon;
```
In the `Main` function (or a function with a similar meaning (like `App` in a `App.xaml.cs` file)) you have to call `InitializeLogger` and specify the location where the logs will be saved (always use a path scheme similar to this example):
The Always on Top module allows users to pin windows on top of others, ensuring they remain visible even when switching between applications. The module provides visual indicators (customizable borders) to identify which windows are pinned.
## Features
- Pin any window to stay on top of other windows
- Customizable border color, opacity, and thickness around pinned windows
- User-defined keyboard shortcut for toggling window pinning
- Visual indicators to identify pinned windows
## Architecture
### Main Components
- **Hotkey Listener**: Detects the user-defined hotkey to toggle the Always on Top state
- **AlwaysOnTop**: Manages the state of windows, ensuring the selected window stays on top
- **Settings**: Stores user preferences and configurations
- **WindowHook**: Hooks all window events
### Data Flow
1. The Hotkey Listener detects the hotkey press and notifies the AlwaysOnTop
2. The AlwaysOnTop updates the window state and interacts with the operating system to keep the window on top
3. User preferences are saved and loaded from the Settings
## Code Structure
### Key Files
- **AlwaysOnTop.cpp**: Contains the core logic for the module, including initialization and event handling
- **Settings.cpp**: Defines the settings structure and provides methods to load and save settings
- **main.cpp**: Starts thread and initializes AlwaysOnTop
### Initialization
The module is initialized in the AlwaysOnTop class. During initialization, the following steps are performed:
1.**LoadSettings**: The module loads user settings from a configuration file
2.**RegisterHotkey**: The HotkeyManager registers the keyboard shortcut for pinning/unpinning windows
3.**SubscribeToEvents**: Event handlers are attached to respond to user actions, such as pressing the hotkey
### Pinning and Unpinning Windows
The AlwaysOnTop class handles the pinning and unpinning of windows. Key methods include:
- **PinTopmostWindow**: Pins the specified window on top of others and applies visual indicators
- **UnpinTopmostWindowss**: Removes the pinning status and visual indicators from the specified window
- **AssignBorder**: Applies a colored border around the pinned window based on user settings
### Settings Management
The Settings class manages the module's settings. Key methods include:
- **LoadSettings**: Loads settings from a configuration file
- **NotifyObservers**: Distributes the data for the settings
- **GetDefaultSettings**: Returns the default settings for the module
## User Interface
The module provides a user interface for configuring settings in the PowerToys Settings UI. This interface is implemented using XAML and includes options for customizing the:
- Border color
- Border opacity
- Border thickness
- Keyboard shortcut
## Development Environment Setup
### Prerequisites
- Visual Studio 2019 or later
- Windows 10 SDK
- PowerToys repository cloned from GitHub
### Building and Testing
1. Clone the repository: `git clone https://github.com/microsoft/PowerToys.git`
2. Open PowerToys.sln in Visual Studio
3. Select the Release configuration and build the solution
4. Run PowerToys.exe from the output directory to test the module
### Debug
1. build the entire project
2. launch the built Powertoys
3. select AlwaysOnTop as the startup project in VS
4. In the debug button, choose "Attach to process". 
5. Attach to AlwaysOnTop.
Awake is a PowerToys utility designed to keep your computer awake without permanently modifying system power settings. It prevents the computer from sleeping and can keep the monitor on, providing a convenient alternative to changing system power configurations.
## Key Features
- Temporarily override system sleep settings
- Keep monitor on (prevent display from turning off)
- Set time intervals for keeping the system awake
- One-time setup with no need to revert power settings afterward
## Advantages Over System Power Settings
- **Convenience**: Easy UI for quick toggling of sleep prevention
- **Flexibility**: Support for different time intervals (indefinitely, for specific duration)
- **Non-persistent**: Changes are temporary and don't require manual reversion
- **Quick Access**: Available directly from the system tray
## Architecture
### Components
- **System Tray UI**: Provides user interface for controlling Awake settings
- **Backend Threads**: Manages the power state prevention functionality
- **Command Line Interface**: Supports various commands for controlling Awake functionality programmatically
## Technical Implementation
Awake works by preventing system sleep through Windows power management APIs. The module runs as a background process that interfaces with the Windows power management system to keep the device awake according to user preferences.
## User Experience
Users can access Awake through the PowerToys system tray icon. From there, they can:
1. Toggle Awake on/off
2. Set a specific duration for keeping the system awake
3. Choose whether to keep the display on or allow it to turn off
4. Access additional configuration options
## Command Line Support
Awake includes command-line functionality for power users and automation scenarios, allowing programmatic control of the utility's features.
Color Picker is a system-wide color picking utility for Windows that allows users to pick colors from any screen and copy them to the clipboard in a configurable format.
## Implementation Details
### Color Capturing Mechanism
The Color Picker works by following these steps to capture the color at the current mouse position:
1. Obtain the position of the mouse
2. Create a 1x1 size rectangle at that position
3. Create a Bitmap class and use it to initiate a Graphics object
4. Create an image associated with the Graphics object by leveraging the CopyFromScreen function, which captures the pixel information from the specified location
### Core Color Picking Function
The following code snippet demonstrates the core functionality of how a color is picked from the screen:
- View color information in various formats (RGB, HEX, HSL, etc.)
- Copy color values to clipboard in configurable formats
- Color history for quick access to previously selected colors
- Keyboard shortcuts for quick activation and operation
## User Experience
When activated, Color Picker displays a magnified view of the area around the cursor to allow for precise color selection. Once a color is selected, it can be copied to the clipboard in the user's preferred format for use in design tools, development environments, or other applications.
Command Not Found is a PowerToys module that suggests package installations when you attempt to run a command that isn't available on your system. It integrates with the Windows command line to provide helpful suggestions for installing missing commands through package managers.
## How it Works
When you attempt to execute a command in the terminal that isn't found, the Command Not Found module intercepts this error and checks if the command is available in known package repositories. If a match is found, it suggests the appropriate installation command.
## Installation
The Command Not Found module requires the Microsoft.WinGet.CommandNotFound PowerShell module to function properly. When enabling the module through PowerToys, it automatically attempts to install this dependency.
The installation is handled by the following script:
```powershell
# Located in PowerToys\src\settings-ui\Settings.UI\Assets\Settings\Scripts\EnableModule.ps1
1. Enable the Command Not Found module in PowerToys settings.
2. Open a terminal and try to run a command that isn't installed on your system.
3. If the command is available in a package, you'll see a suggestion for how to install it.
Example:
```
C:\> kubectl
'kubectl' is not recognized as an internal or external command, operable program, or batch file.
Command 'kubectl' not found, but can be installed with:
winget install -e --id Kubernetes.kubectl
```
## Technical Details
The Command Not Found module leverages the Microsoft.WinGet.CommandNotFound PowerShell module, which is maintained in a separate repository: https://github.com/microsoft/winget-command-not-found
The module works by registering a command-not-found handler that intercepts command execution failures and provides installation suggestions based on available packages in the WinGet repository.
The Crop and Lock module in PowerToys allows users to crop a current application into a smaller window or create a thumbnail. This utility enhances productivity by enabling users to focus on specific parts of an application window.
## Features
### Thumbnail Mode
Creates a window showing the selected area of the original window. Changes in the original window are reflected in the thumbnail.
### Reparent Mode
Creates a window that replaces the original window, showing only the selected area. The application is controlled through the cropped window.
## Code Structure
### Project Layout
The Crop and Lock module is part of the PowerToys solution. All the logic-related settings are in the main.cpp. The main implementations are in ThumbnailCropAndLockWindow and ReparentCropAndLockWindow. ChildWindow and OverlayWindow distinguish the two different modes of windows implementations.
### Key Files
- **ThumbnailCropAndLockWindow.cpp**: Defines the UI for the thumbnail mode.
Environment Variables is a PowerToys module that provides an easy and convenient way to manage Windows environment variables. It offers a modern user interface for viewing, editing, and managing both user and system environment variables.
## Features
- View and edit user and system environment variables in a unified interface
- Create profiles to group and manage sets of variables together
- Profile-based variable management with on/off toggles
- Automatic backup of existing variables when overridden by a profile
- Restoration of original values when profiles are disabled
## How It Works
### Profiles
Profiles are collections of environment variables that can be enabled or disabled together. When a profile is enabled:
1. Variables in the profile override existing User variables with the same name
2. Original values are automatically backed up for restoration when the profile is disabled
3. Only one profile can be active at a time
### Variable Precedence
The module follows this precedence order for environment variables:
1. Active profile variables (highest precedence)
2. User variables
3. System variables (lowest precedence)
## Architecture
The Environment Variables module is structured into three main components:
### Project Structure
```
EnvironmentVariables/ # Contains assets, main windows, and telemetry
EnvironmentVariablesModuleInterface # Interface definitions and package configurations
EnvironmentVariableUILib # Abstracted UI methods and implementations
```
### Key Components
- **Main Window Framework**: Builds the modern Windows desktop UI, handles Windows messages, resource loading, and window closing operations
- **Project Configuration**: Defines settings and configurations for the module
- **UI Implementation**: Contains the user interface components and the backend logic
## Implementation Details
### Key Functions
- **OpenEnvironmentKeyIfExists**: Accesses environment information through registry keys
- **SetEnvironmentVariableFromRegistryWithoutNotify**: Sets variables directly to registry instead of using Environment API, avoiding the 1-second timeout for settings change notifications
- **GetVariables**: Reads variables directly from registry instead of using Environment API to prevent automatic variable expansion
### Technical Notes
- The module reads and writes variables directly to the registry instead of using the Environment API
- This direct registry access approach is used because the Environment API automatically expands variables and has a timeout for notifications
- When a profile variable has the same name as an existing User variable, a backup is created with a naming pattern: `VARIABLE_NAME_powertoys_PROFILE_NAME`
FancyZones has several specialized debugging tools to help diagnose issues with window management, zone detection, and rendering. These tools are designed to isolate and test specific components of the FancyZones functionality.
## Tools Summary
| Tool | Purpose | Key Functionality |
|------|---------|-------------------|
| FancyZones_HitTest | Tests zone hit detection | Shows which zone is under cursor with detailed metrics |
| FancyZones_DrawLayoutTest | Tests layout drawing | Renders zone layouts to debug display issues |
| FancyZones_zonable_tester | Tests window zonability | Determines if windows can be placed in zones |

### Purpose
Tests the FancyZones layout selection logic by displaying a window with zones and highlighting the zone under the mouse cursor.
### Functionality
- Displays a window with 5 sample zones
- Highlights the zone under the mouse cursor
- Shows metrics used for zone detection in a sidebar
- Helps diagnose issues with zone positioning and hit testing
### Usage
- Run the tool and move your mouse over the zones
- The currently detected zone will be highlighted
- The sidebar displays metrics used for determining the active zone
- Useful for debugging hit detection, positioning, and DPI issues
## FancyZones_DrawLayoutTest
### Purpose
Debug issues related to the drawing of zone layouts on screen.
### Functionality
- Simulates zone layouts (currently only column layout supported)
- Tests rendering of zones with different configurations
- Helps diagnose display issues across monitor configurations
### Usage
- Run the tool
- Press **W** key to toggle zone appearance on the primary screen
- Press **Q** key to exit the application
- The number of zones can be modified in the source code
### Technical Notes
The application is DPI unaware, meaning it doesn't scale for DPI changes and always assumes a scale factor of 100% (96 DPI). Scaling is automatically performed by the system.
## FancyZones_zonable_tester

### Purpose
Tests if the window under the mouse cursor is "zonable" (can be placed in a FancyZones zone).
### Functionality
- Analyzes the window under the cursor
- Provides detailed window information:
* HWND (window handle)
* Process ID
* HWND of foreground window
* Window style flags
* Extended style flags
* Window class
* Process path
### Usage
- Run the command-line application
- Hover the mouse over a window to test
- Review the console output for detailed window information
- Check if the window is considered zonable by FancyZones
### Limitations
Note that this tool may not be fully up-to-date with the latest zonable logic in the main FancyZones codebase.
## StylesReportTool
### Purpose
Generates detailed reports about window styles that affect zonability.
### Functionality
- Creates comprehensive window style reports
- Focuses on style flags that determine if windows can be placed in zones
- Outputs report to "WindowStyles.txt" on the desktop
### Usage
- Run the tool
- Focus the window you want to analyze
- Press **Ctrl+Alt+S** to generate a report
- Review WindowStyles.txt to understand why a window might not be zonable
## Debugging Workflow
For most effective debugging of FancyZones issues:
1. Use **StylesReportTool** to analyze window properties of problematic windows
2. Use **FancyZones_zonable_tester** to check if specific windows can be zoned
3. Use **FancyZones_draw** for layout rendering issues on different monitors
4. Use **FancyZones_HitTest** for diagnosing zone detection problems
## Testing Considerations
When testing FancyZones with these tools, consider:
- Testing on different Windows versions
- Testing with multiple monitors with different:
* Resolutions
* Scaling settings
* Physical arrangements
- Testing with various window types:
* Standard applications
* Legacy applications
* UWP/WinUI applications
* Administrative windows
* Special windows (like Task Manager)
- Testing various layouts:
* Grid layouts
* Custom layouts
* Overlapping zones
## Initial Setup Issues
If encountering JSON token errors on first run:
1. Launch FancyZones Editor through PowerToys Settings UI
2. This initializes required configuration files
3. Direct project execution won't initialize configs properly
3. Select the Release configuration and build the solution
4. If you encounter build errors, try deleting the x64 output folder and rebuild
## Getting Started with FancyZones Development
### Step 1: Familiarize with the Feature
- Use the feature to understand its functionality
- Read the official documentation: [PowerToys FancyZones utility for Windows](https://learn.microsoft.com/en-us/windows/powertoys/fancyzones)
### Step 2: Build and Debug
- Ensure you can successfully compile and debug the module
- First-time setup may require running the Editor through PowerToys Settings UI to initialize configuration files
### Step 3: Learn through Bug Fixes
- Examine existing bugs and feature requests to understand code structure
- Use debugging to trace code execution for specific features
- Examine UI test code to understand how features are tested
## Debugging
### Setup for Debugging
1. In Visual Studio 2022, set FancyZonesEditor as the startup project
2. Set breakpoints in the code where needed
3. Click Run to start debugging
### During Active Development
- You can perform breakpoint debugging to troubleshoot issues
- Attach to running processes if needed to debug the module in context
### Common Debugging Issues
- If encountering JSON errors on first run, launch the FancyZones Editor once through PowerToys Settings UI to initialize required configuration files
- For UI-related issues, use tools like AccessibilityInsights to inspect element properties
## Deployment and Release Process
### Deployment
#### Local Testing
1. Build the solution in Visual Studio
2. Run PowerToys.exe from the output directory
#### Packaging
- Use the MSIX packaging tool to create an installer
- Ensure all dependencies are included
### Release
#### Versioning
- Follow semantic versioning for releases
#### Release Notes
- Document all changes, fixes, and new features
#### Publishing
1. Create a new release on GitHub
2. Upload the installer and release notes
## Troubleshooting
### First Run JSON Error
**Error**: "The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true. Path: $ | LineNumber: 0 | BytePositionInLine: 0."
**Solution**: Launch the FancyZones Editor once through PowerToys Settings UI. Running the Editor directly within the project will not initialize the required configuration files.
### Known Issues
- Potential undiscovered bugs related to data updates in the Editor
- Some automated tests pass in CI but fail on specific machines
- Complex testing requirements across different monitor configurations
## FancyZones UI Testing
UI tests are implemented using [Windows Application Driver](https://github.com/microsoft/WinAppDriver).
## Before running tests
### Before running tests
- Install Windows Application Driver v1.2.1 from https://github.com/microsoft/WinAppDriver/releases/tag/v1.2.1.
- Enable Developer Mode in Windows settings
## Running tests
### Running tests
- Exit PowerToys if it's running
- Run WinAppDriver.exe from the installation directory. Skip this step if installed in the default directory (`C:\Program Files (x86)\Windows Application Driver`); in this case, it'll be launched automatically during tests.
@@ -16,11 +249,239 @@ UI tests are implemented using [Windows Application Driver](https://github.com/m
>Note: notifications or other application windows, that are shown above the window under test, can disrupt the testing process.
### UI Test Automation
## Extra tools and information
FancyZones is currently undergoing a UI Test migration process to improve automated testing coverage. You can track the progress of this migration at:
[FancyZones UI Test Migration Progress](https://github.com/microsoft/PowerToys/blob/feature/UITestAutomation/src/modules/fancyzones/UITests-FancyZonesEditor/release-test-checklist.md)
### Testing Strategy
#### Unit Tests
- Build the unit test project
- Run using the Visual Studio Test Explorer (`Test > Test Explorer` or `Ctrl+E, T`)
#### Integration Tests
- Ensure the entire FancyZones module works as expected
- Test different window layouts and snapping behaviors
### Test Framework Structure
#### UI Test Requirements
All test cases require pre-configured user data and must reset this data before each test.
**Required User Data Files**:
- EditorParameters
- AppliedLayouts
- CustomLayouts
- DefaultLayouts
- LayoutHotkeys
- LayoutTemplates
- AppZoneHistory
#### Editor Test Suite
**ApplyLayoutTest.cs**
- Verifies layout application and selection per monitor
- Tests file updates and behavior under display switching
- Validates virtual desktop changes
**CopyLayoutTests.cs**
- Tests copying various layout types
- Validates UI and file correctness
**CreateLayoutTests.cs**
- Tests layout creation and cancellation
- Focuses on file correctness validation
**CustomLayoutsTests.cs**
- Tests user-created layout operations
- Covers renaming, highlight line changes, zone count changes
**DefaultLayoutsTest.cs**
- Validates default and user layout files
**DeleteLayoutTests.cs**
- Tests layout deletion across types
- Checks both UI and file updates
**EditLayoutTests.cs**
- Tests zone operations: add/delete/move/reset/split/merge
**FirstLaunchTest.cs**
- Verifies Editor launches correctly on first run
**LayoutHotkeysTests.cs**
- Tests hotkey configuration file correctness
- Note: Actual hotkey behavior tested in FancyZones backend
**TemplateLayoutsTests.cs**
- Tests operations on built-in layouts
- Covers renaming, highlight changes, zone count changes
#### FancyZones Backend Tests
**LayoutApplyHotKeyTests.cs**
- Focuses on hotkey-related functionality
- Tests actual hotkey behavior implementation
### UI Testing Tools
While working on tests, you may need tools to view element accessibility data:
>Note: Close helper tools while running tests. Overlapping windows can affect test results.
2. FancyZones might have implemented certain screen resolution limits in the code that do not support such wide screens
3. User error — it can be seen that no layout has been applied to the screen, so it's normal that the far right is not displayed, as the user hasn't used the FancyZones feature
4. From the image, it appears the user is trying to maximize a game window, but some games may not support rendering windows at such high resolutions due to internal implementation
The **optimal solution** for this bug is to first comment on the user's usage issue. Let them correctly use the FancyZones feature before making further judgments. If the issue persists after proper usage, then investigate whether it's a code issue or a problem with the game itself.
To demonstrate a debugging example, I will assume it's a code issue, specifically an issue with the Editor. Please see the following debug process.
Let's first locate the corresponding code. Since the error is in the Editor, we'll start by checking the FancyZonesEditor shown in the image.

However, I currently don't know where the code for this specific UI element in the Editor is located.

We now have two approaches to find the exact code location.
**First approach:**
The main XAML page is usually named `App.xaml` or `MainWindow.xaml`. Let's start by locating these two files in the FancyZones Editor. Upon reviewing their contents, we find that `App.xaml` is primarily a wrapper file and doesn't contain much UI code. Therefore, it's highly likely that the UI code is located in `MainWindow.xaml`. In the preview of `MainWindow.xaml`, we can also see a rough outline of the UI elements.
By searching for "monitor", we found that only lines 82 and 338 contain the string "monitor".
Then, upon reviewing the code, we found that the line at 82 is part of a template. The UI element we're looking for is located within the code block around line 338.
**Second approach:**
We can use the **AccessibilityInsights** tool to inspect the specific information of the corresponding UI element.

However, the current UI element does not have an AutomationId. Let's check whether its parent or child nodes have an AutomationId value. (In fact, using ClassName could also help locate it, but elements with the same ClassName might be numerous, making AutomationId a more accurate option.)

We found that the parent node "List View" has an AutomationId value. Copy this value and search for it in the code.

**Accurately located at line 338.**
Now that we've found the code for the UI element, let's look at where the size data for this UI element comes from. First, the text of this `Text` element is bound within the `MonitorItemTemplate`. The name of this `Text` element is `ResolutionText`, and it binds to a data property named `Dimensions`.

Search for code related to `Dimensions` across all projects in FancyZones.

We found that this string corresponds to a variable. However, the return value differs in Debug mode, so let's first examine the logic in Release mode.
We found that the variable `ScreenBoundsWidth` is located in the constructor of `MonitorInfoModel`.

Then, by searching for `MonitorInfoModel`, we found that this class is instantiated in the constructor of the `MonitorViewModel` class.

The width and height of the monitor, which are crucial, are also assigned at this point. Let's continue by checking where the data in `App.Overlay.Monitors` is initialized.
My idea is to examine all references to the `Monitors` variable and identify the initialization point based on those references.

Finally, by tracing the `Add` function of `Monitors`, we found the `AddMonitor()` method. This method is only called by `ParseParams()`, which confirms that the data originates from there.
However, by examining the context around the `AddMonitor()` function, we can see that the data comes from the `editor-parameters.json` file. Next, we will continue to investigate how this file is initialized and modified.

By searching, we found that the `editor-parameters.json` file has write functions in both the Editor and FancyZones projects.

**The display information is retrieved through the following call stack:**
**How was the `UpdateWorkAreas()` function identified?**
It was discovered by searching for `EditorParameters` and noticing that when the `save` function is called on `EditorParameters`, the parameter passed is `m_workAreaConfiguration`.

**Then, by checking the initialization location of the `m_workAreaConfiguration` variable, we found that it is initialized inside `UpdateWorkAreas`.**
With this, we have successfully identified the source of the monitor resolution data displayed in the Editor's `Monitors` section.
### Step Four:
Familiarize yourself with the module code through the current tasks at hand.
[Task 57329836: PowerToys UI Test FancyZone UI Test Override Windows Snap-1 - Boards](https://microsoft.visualstudio.com/OS/_workitems/edit/57329836/)
[Task 57329843: PowerToys UI Test FancyZone UI Test Override Windows Snap-2 - Boards](https://microsoft.visualstudio.com/OS/_workitems/edit/57329843/)
[Task 57329845: PowerToys UI Test FancyZone UI Test Override Windows Snap-3 - Boards](https://microsoft.visualstudio.com/OS/_workitems/edit/57329845/)
[Task 56940387: PowerToys UI Test FancyZone UI Test Override Windows Snap-4 - Boards](https://microsoft.visualstudio.com/OS/_workitems/edit/56940387/)
UI Test Check List:
PowerToys/doc/releases/tests-checklist-template.md at releaseChecklist · microsoft/PowerToys](https://github.com/microsoft/PowerToys/blob/releaseChecklist/doc/releases/tests-checklist-template.md)
## Q&A
- ### First Run FancyZones error

If you encounter this situation, you need to launch the FancyZones Editor once in the powertoys settings UI (Refer to the image below). The reason is that running the Editor directly within the project will not initialize various configuration files.

- ### How are layouts stored and loaded? Is there a central configuration handler?
There is no central configuration handler.
Editor read/write config data handler is in FancyZonesEditorCommon project.

FancyZones cpp project read/write config data handler is in FancyZonesLib project.

However, the files write and read those are C:\Users\“xxxxxx”\AppData\Local\Microsoft\PowerToys\FancyZones
You can think of the editor as a visual config editor, which is most of its functionality. Another feature is used to set the layout for the monitor displays.
When the Editor starts, it will load the config data, and when FancyZones starts, it will also load the config data. After the Editor updates the config data, it will send a data update event, and FancyZones will refresh the current data in memory upon receiving the event.

- ### Which parts of the code are responsible for monitor detection and DPI scaling?
About monitor detection you can find "FancyZones::MoveSizeUpdate" function.
I believe that in the case without DPI scaling, FancyZones retrieves the window's position and does not need to know what the mouse's DPI scaling is like. If you are referring to window scaling, it is called through the system interface, and you can see the detailed code in "WindowMouseSnap::MoveSizeEnd()" fucntion.
- ### How does FancyZones track which windows belong to which zones?
While working on tests, you may need a tool that helps you to view the element's accessibility data, e.g. for finding the button to click. For this purpose, you could use [AccessibilityInsights](https://accessibilityinsights.io/docs/windows/overview) or [WinAppDriver UI Recorder](https://github.com/microsoft/WinAppDriver/wiki/WinAppDriver-UI-Recorder).
>Note: close helper tools while running tests. Overlapping windows can affect test results.
>Note: close helper tools while running tests. Overlapping windows can affect test results.
File Locksmith is a utility in PowerToys that shows which processes are locking or using a specific file. This helps users identify what's preventing them from deleting, moving, or modifying files by revealing the processes that have handles to those files.
## Architecture

File Locksmith follows a similar architecture to the ImageResizer and NewPlus modules. It consists of:
1.**Shell Extensions**:
-`FileLocksmithExt` - COM-based shell extension for Windows 10 and below
-`FileLocksmithContextMenu` - Shell extension for Windows 11 context menu
2.**Core Components**:
-`FileLocksmithLib` - Handles IPC between shell extensions and UI
-`FileLocksmithLibInterop` - Core functionality for finding processes locking files
-`FileLocksmithUI` - WinUI 3 user interface component
3.**Settings Integration**:
- Settings integration in the PowerToys settings application
## Implementation Details
### Shell Extensions
The module adds "Unlock with File Locksmith" to the context menu in File Explorer:
- For Windows 11, a context menu command is registered as a MSIX sparse package (compiled via appxmanifest.xml)
- For Windows 10 and below, a traditional shell extension is registered through registry keys during installation
### Process Communication Flow
1. User enables File Locksmith in PowerToys settings
2. User right-clicks on a file and selects "Unlock with File Locksmith"
3. The shell extension writes the selected file path to a temporary file (file-based IPC)
4. The shell extension launches `PowerToys.FileLocksmithUI.exe`
5. The UI reads the file path from the temporary file
6. The UI uses `FileLocksmithLibInterop` to scan for processes with handles to the file
7. Results are displayed in the UI, showing process information and allowing user action
### Core Functionality
The core functionality to find processes locking files is implemented in [FileLocksmith.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/FileLocksmith.cpp), which:
- Uses low-level Windows APIs via `NtdllExtensions` to iterate through file handles
- Examines all running processes to find handles to the specified files
- Maps process IDs to the files they're locking
- Retrieves process information such as name, user context, and file paths
### User Interface
The UI is built with WinUI 3 and uses MVVM architecture:
- View models handle process data and user interactions
- Converters transform raw data into UI-friendly formats
- The interface shows which processes are locking files, along with icons and process details
## Code Structure
### Shell Extensions
- [ClassFactory.cpp](/src/modules/FileLocksmith/FileLocksmithExt/ClassFactory.cpp): COM class factory that creates instances of shell extension objects
- [ExplorerCommand.cpp](/src/modules/FileLocksmith/FileLocksmithExt/ExplorerCommand.cpp): Implements Windows Explorer context menu command for Windows 10 and below
- [PowerToysModule.cpp](/src/modules/FileLocksmith/FileLocksmithExt/PowerToysModule.cpp): PowerToys module interface implementation with settings management
- [dllmain.cpp](/src/modules/FileLocksmith/FileLocksmithExt/dllmain.cpp): DLL entry point for Windows 10 shell extension
- [dllmain.cpp](/src/modules/FileLocksmith/FileLocksmithContextMenu/dllmain.cpp): Windows 11 context menu integration through MSIX package
### Core Libraries
- [IPC.cpp](/src/modules/FileLocksmith/FileLocksmithLib/IPC.cpp): File-based inter-process communication between shell extensions and UI
- [Settings.cpp](/src/modules/FileLocksmith/FileLocksmithLib/Settings.cpp): Settings management for File Locksmith module
- [FileLocksmith.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/FileLocksmith.cpp): Core process scanning implementation to find processes locking files
- [NativeMethods.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/NativeMethods.cpp): Interop layer bridging native C++ with WinRT-based UI
- [NtdllBase.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/NtdllBase.cpp): Interface to native Windows NT APIs
- [NtdllExtensions.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/NtdllExtensions.cpp): Process and handle querying utilities using NtQuerySystemInformation
- [ProcessResult.cpp](/src/modules/FileLocksmith/FileLocksmithLibInterop/ProcessResult.cpp): Class for storing process information (name, PID, user, file list)
### UI Components
- [FileCountConverter.cs](/src/modules/FileLocksmith/FileLocksmithUI/Converters/FileCountConverter.cs): Converts file counts for UI display
- [FileListToDescriptionConverter.cs](/src/modules/FileLocksmith/FileLocksmithUI/Converters/FileListToDescriptionConverter.cs): Formats file lists for display
- [PidToIconConverter.cs](/src/modules/FileLocksmith/FileLocksmithUI/Converters/PidToIconConverter.cs): Extracts icons for processes
- [UserToSystemWarningVisibilityConverter.cs](/src/modules/FileLocksmith/FileLocksmithUI/Converters/UserToSystemWarningVisibilityConverter.cs): Shows warnings for system processes
- [MainWindow.xaml.cs](/src/modules/FileLocksmith/FileLocksmithUI/FileLocksmithXAML/MainWindow.xaml.cs): Main application window implementation
- [App.xaml.cs](/src/modules/FileLocksmith/FileLocksmithUI/FileLocksmithXAML/App.xaml.cs): Application entry point
- [MainViewModel.cs](/src/modules/FileLocksmith/FileLocksmithUI/ViewModels/MainViewModel.cs): Main view model that handles loading processes asynchronously
### Settings Integration
- [FileLocksmithViewModel.cs](/src/settings-ui/Settings.UI/ViewModels/FileLocksmithViewModel.cs): ViewModel for File Locksmith in PowerToys settings
SignTool might be not in your PATH, so you may need to specify the full path to it, e.g., `C:\Program Files (x86)\Windows Kits\10\bin\<version>\x64\signtool.exe`.
- Set the breakpoint in [dllmain.cpp](/src/modules/FileLocksmith/FileLocksmithContextMenu/dllmain.cpp#L116)
- Open the **Attach to Process** dialog in Visual Studio
- Right-click a file in File Explorer
- Attach the debugger to `dllhost.exe` with **FileLocksmith** Title to debug the shell extension

- Right-click (fast) a file again and select *"Unlock with File Locksmith"*
- Attach the debugger to `PowerToys.FileLocksmithUI.exe` to debug the UI
7. **Alternative Debugging Method**
- You can set the `FileLocksmithUI` as startup project directly in Visual Studio, which will launch the UI without needing to go through the shell extension. This is useful for debugging the UI logic without the shell extension overhead.
## Known Issues
There is an open PR to change the IPC mechanism from file-based to pipe-based, but it has blockers:
- When restarting as admin, the context menu extension doesn't show
- The "Unlock with File Locksmith" option doesn't work when launched as admin
## Settings Integration
File Locksmith integrates with the PowerToys settings through:
The Hosts File Editor module provides a convenient way to edit the system's hosts file. The hosts file is a plain text file used by the operating system to map hostnames to IP addresses, allowing users to override DNS for specific domain names.
## Code Structure

The Hosts File Editor module is structured into three primary components:
1.**Hosts** - Entry point for the Hosts File Editor. Manages core services and settings through helper utilities.
2.**HostsModuleInterface** - Interface for integrating the Hosts module with the PowerToys system.
3.**HostsUILib** - Implements the UI layer using WinUI 3.
This structure is similar to the Environment Variables for Windows module.
- [HostsXAML](/src/modules/Hosts/Hosts/HostsXAML): Initialize service and loads the main window
- [Host.cs](/src/modules/Hosts/Hosts/Helpers/Host.cs): Access to services register
- [NativeEventWaiter.cs](/src/modules/Hosts/Hosts/Helpers/NativeEventWaiter.cs): Gets the dispatcher queue for posting UI updates from a background thread
- [UserSettings.cs](/src/modules/Hosts/Hosts/Settings/UserSettings.cs): Manages reading, tracking, and updating user settings from settings.json
#### HostsUILib
- [HostsMainPage.xaml.cs](/src/modules/Hosts/HostsUILib/HostsMainPage.xaml.cs): Main page
- [ViewModels](/src/modules/Hosts/HostsUILib/ViewModels): Contains view models that manage state and logic
- [Models](/src/modules/Hosts/HostsUILib/Models): Models for managing host entries
- [AddressType.cs](/src/modules/Hosts/HostsUILib/Models/AddressType.cs): Specifies whether an address is IPv4, IPv6, or Invalid
- [Entry.cs](/src/modules/Hosts/HostsUILib/Models/Entry.cs): Represents a single hosts file entry (IP address, hostnames, comment, flags)
- [HostsData.cs](/src/modules/Hosts/HostsUILib/Models/HostsData.cs): Converts the list of entries into a read-only collection
| Additional lines position | `UserSettings()->AdditionalLinesPosition` |
| Consider loopback addresses as duplicates | `UserSettings()->LoopbackDuplicates` |
| Encoding Setting | `UserSettings()->Encoding` |
## UI Test Automation
Hosts File Editor is currently undergoing a UI Test migration process to improve automated testing coverage. You can track the progress of this migration at:
[Hosts File Editor UI Test Migration Progress](https://github.com/microsoft/PowerToys/blob/feature/UITestAutomation/src/modules/Hosts/Hosts.UITests/Release-Test-Checklist-Migration-Progress.md)
Image Resizer is a Windows shell extension that enables batch resizing of images directly from File Explorer.
## Overview
Image Resizer provides a convenient way to resize images without opening a dedicated image editing application. It is accessible through the Windows context menu and allows users to:
- Resize single or multiple images at once
- Choose from predefined sizing presets or enter custom dimensions
- Maintain or modify aspect ratios
- Create copies or overwrite original files
- Apply custom filename formats to resized images
- Select different encoding quality settings
## Architecture
Image Resizer consists of multiple components:
- Shell Extension DLL (context menu integration)
- WinUI 3 UI application
- Core image processing library
### Technology Stack
- C++/WinRT
- WPF (UI components)
- Windows Imaging Component (WIC) for image processing
- COM for shell integration
## Context Menu Integration
Image Resizer integrates with the Windows context menu following the [PowerToys Context Menu Handlers](../common/context-menus.md) pattern. It uses a dual registration approach to ensure compatibility with both Windows 10 and Windows 11.
### Registration Process
The context menu integration follows the same pattern as PowerRename, using:
- A traditional shell extension for Windows 10
- A sparse MSIX package for Windows 11 context menus
For more details on the implementation approach, see the [Dual Registration section](../common/context-menus.md#1-dual-registration-eg-imageresizer-powerrename) in the context menu documentation.
### Context Menu Appearance Logic
Image Resizer dynamically determines when to show the context menu option:
-`AppxManifest.xml` registers the extension for all file types (`Type="*"`)
- The shell extension checks if the selected files are images using `AssocGetPerceivedType()`
- The menu appears only for image files (returns `ECS_ENABLED`), otherwise it remains hidden (returns `ECS_HIDDEN`)
This approach provides flexibility to support additional file types by modifying only the detection logic without changing the system-level registration.
## UI Implementation
Image Resizer uses WPF for its user interface, as evidenced by the App.xaml.cs file. The UI allows users to:
- Select from predefined size presets or enter custom dimensions
- Configure filename format for the resized images
- Set encoding quality and format options
- Choose whether to replace or create copies of the original files
From the App.xaml.cs file, we can see that the application:
- Supports localization through `LanguageHelper.LoadLanguage()`
- Processes command line arguments via `ResizeBatch.FromCommandLine()`
- Uses a view model pattern with `MainViewModel`
- Respects Group Policy settings via `GPOWrapper.GetConfiguredImageResizerEnabledValue()`
## Debugging
### Debugging the Context Menu
See the [Debugging Context Menu Handlers](../common/context-menus.md#debugging-context-menu-handlers) section for general guidance on debugging PowerToys context menu extensions.
For Image Resizer specifically, there are several approaches:
#### Option 1: Manual Registration via Registry
1. Create a registry file (e.g., `register.reg`) with the following content:
Enable detailed logging by setting the `_DEBUG` and `KBM_VERBOSE_LOGGING` preprocessor definitions.
## Common Issues and Troubleshooting
### Multiple Instances
If you encounter issues with multiple instances, check the mutex logic in `KeyboardManagerEditor.cpp`. The editor uses `PowerToys_KBMEditor_InstanceMutex` to ensure single instance.
### Key Events Not Being Intercepted
1. Verify the hook is properly installed by setting a breakpoint in the hook procedure
2. Check if any other application is capturing keyboard events at a lower level
3. Ensure the correct configuration is being loaded from the settings JSON
### UI Freezes or Crashes
1. Check XAML Islands initialization in the Editor
2. Verify UI thread is not being blocked by IO operations
3. Look for exceptions in the event handling code
## Advanced Debugging
### Debugging Both Components Simultaneously
To debug both the Editor and Engine:
1. Launch the Engine first in debug mode
2. Attach the debugger to the Editor process when it starts
Find My Mouse is a utility that helps users locate their mouse pointer by creating a spotlight effect when activated. It is based on Raymond Chen's SuperSonar utility.
## Implementation
Find My Mouse displays a spotlight effect centered on the cursor location when activated via a keyboard shortcut (typically a double-press of the Ctrl key).
### Key Files
-`src/modules/MouseUtils/FindMyMouse/FindMyMouse.cpp` - Contains the main implementation
- Key function: `s_WndProc` - Handles window messages for the utility
### Enabling Process
When the utility is enabled:
1. A background thread is created to run the Find My Mouse logic asynchronously:
Logger::error("Couldn't initialize a sonar instance.");
return 0;
}
m_sonar = &sonar;
```
3. The utility listens for raw input events using `WM_INPUT`, which provides more precise and responsive input detection than standard mouse events.
### Activation Process
The activation process works as follows:
1. **Keyboard Hook Detects Shortcut**
- A global low-level keyboard hook is set up during initialization
- The hook monitors for the specific activation pattern (double Ctrl press)
- Once matched, it sends a `WM_PRIV_SHORTCUT` message to the sonar window:
```cpp
virtual void OnHotkeyEx() override
{
Logger::trace("OnHotkeyEx()");
HWND hwnd = GetSonarHwnd();
if (hwnd != nullptr)
{
PostMessageW(hwnd, WM_PRIV_SHORTCUT, NULL, NULL);
}
}
```
2. **Message Handler Triggers Action**
- The custom message is routed to `BaseWndProc()`
- The handler toggles the sonar animation:
```cpp
if (message == WM_PRIV_SHORTCUT)
{
if (m_sonarStart == NoSonar)
StartSonar(); // Trigger sonar animation
else
StopSonar(); // Cancel if already running
}
```
3. **Sonar Animation**
- `StartSonar()` uses `CompositionSpotlight` to display a highlight (ripple/pulse) centered on the mouse pointer
- The animation is temporary and fades automatically or can be cancelled by user input
### Event Handling
The Find My Mouse utility handles several types of events:
- **Mouse Events**: Trigger sonar animations (e.g., after a shake or shortcut)
- **Keyboard Events**: May cancel or toggle the effect
- **Custom Shortcut Messages**: Handled to allow toggling Find My Mouse using a user-defined hotkey
When the main window receives a `WM_DESTROY` message (on shutdown or disable), the sonar instance is properly cleaned up, and the message loop ends gracefully.
## Debugging
To debug Find My Mouse:
- Attach to the PowerToys Runner process directly
- Set breakpoints in the `FindMyMouse.cpp` file
- When debugging the spotlight effect, visual artifacts may occur due to the debugger's overhead
Mouse Highlighter is a utility that visualizes mouse clicks by displaying a highlight effect around the cursor when clicked.
## Implementation
Mouse Highlighter runs within the PowerToys Runner process and draws visual indicators (typically circles) around the mouse cursor when the user clicks.
### Key Files
-`src/modules/MouseUtils/MouseHighlighter/MouseHighlighter.cpp` - Contains the main implementation
Mouse Jump is a utility that allows users to quickly move their cursor to any location on screen using a grid-based overlay interface.
## Implementation
Unlike the other Mouse Utilities that run within the PowerToys Runner process, Mouse Jump operates as a separate process that communicates with the Runner via events.
### Key Files
-`src/modules/MouseUtils/MouseJump` - Contains the Runner interface for Mouse Jump
-`src/modules/MouseUtils/MouseJumpUI` - Contains the UI implementation
-`src/modules/MouseUtils/MouseJumpUI/MainForm.cs` - Main UI form implementation
-`src/modules/MouseUtils/MouseJump.Common` - Shared code between the Runner and UI components
### Enabling Process
When the utility is enabled:
1. A separate UI process is launched for Mouse Jump:
```cpp
void launch_process()
{
Logger::trace(L"Starting MouseJump process");
unsigned long powertoys_pid = GetCurrentProcessId();
Mouse Pointer Crosshairs is a utility that displays horizontal and vertical lines that intersect at the mouse cursor position, making it easier to track the cursor location on screen.
## Implementation
Mouse Pointer Crosshairs runs within the PowerToys Runner process and draws crosshair lines that follow the cursor in real-time.
### Key Files
-`src/modules/MouseUtils/MousePointerCrosshairs/InclusiveCrosshairs.cpp` - Contains the main implementation
Mouse Utilities is a collection of tools designed to enhance mouse and cursor functionality on Windows. The module contains four sub-utilities that provide different mouse-related features.
## Overview
Mouse Utilities includes the following sub-modules:
- **[Find My Mouse](findmymouse.md)**: Helps locate the mouse pointer by creating a visual spotlight effect when activated
- **[Mouse Highlighter](mousehighlighter.md)**: Visualizes mouse clicks with customizable highlights
- **[Mouse Jump](mousejump.md)**: Allows quick cursor movement to specific screen locations
- **[Mouse Pointer Crosshairs](mousepointer.md)**: Displays crosshair lines that follow the mouse cursor
## Architecture
Most of the sub-modules (Find My Mouse, Mouse Highlighter, and Mouse Pointer Crosshairs) run within the PowerToys Runner process as separate threads. Mouse Jump is more complex and runs as a separate process that communicates with the Runner via events.
- **Michael Clayton (@mikeclayton)**: Contributed the initial version of the Mouse Jump tool and several updates based on his FancyMouse utility
- **Raymond Chen (@oldnewthing)**: Find My Mouse is based on Raymond Chen's SuperSonar
## Known Issues
- Mouse Highlighter has a reported bug where the highlight color stays on after toggling opacity to 0
## UI Test Automation
Mouse Utilities is currently undergoing a UI Test migration process to improve automated testing coverage. You can track the progress of this migration at:
[Mouse Utils UI Test Migration Progress](https://github.com/microsoft/PowerToys/blob/feature/UITestAutomation/src/modules/MouseUtils/MouseUtils.UITests/Release-Test-Checklist-Migration-Progress.md)
## See Also
For more detailed implementation information, please refer to the individual utility documentation pages linked above.
#### Activation Process
1. A keyboard hook detects the activation shortcut (typically double-press of Ctrl)
2. A `WM_PRIV_SHORTCUT` message is sent to the sonar window
3.`StartSonar()` is called to display a spotlight animation centered on the mouse pointer
4. The animation automatically fades or can be cancelled by user input
### Mouse Highlighter
Mouse Highlighter visualizes mouse clicks by displaying a highlight effect around the cursor when clicked.
#### Key Components
- Uses Windows Composition API for rendering
- Main implementation in `MouseHighlighter.cpp`
- Core logic handled by the `WndProc` function
#### Activation Process
1. When activated, it creates a transparent overlay window
2. A mouse hook monitors for click events
3. On click detection, the highlighter draws a circle or other visual indicator
4. The highlight effect fades over time based on user settings
### Mouse Pointer Crosshairs
Displays horizontal and vertical lines that intersect at the mouse cursor position.
#### Key Components
- Uses Windows Composition API for rendering
- Core implementation in `InclusiveCrosshairs.cpp`
- Main logic handled by the `WndProc` function
#### Activation Process
1. Creates a transparent, layered window for drawing crosshairs
2. When activated via shortcut, calls `StartDrawing()`
3. Sets a low-level mouse hook to track cursor movement
4. Updates crosshairs position on every mouse movement
5. Includes auto-hide functionality for cursor inactivity
### Mouse Jump
Allows quick mouse cursor repositioning to any screen location through a grid-based UI.
#### Key Components
- Runs as a separate process (`PowerToys.MouseJumpUI.exe`)
- Communicates with Runner process via events
- UI implemented in `MainForm.cs`
#### Activation Process
1. When shortcut is pressed, Runner triggers the shared event `MOUSE_JUMP_SHOW_PREVIEW_EVENT`
2. The MouseJumpUI process displays a screen overlay
3. User selects a destination point on the overlay
4. Mouse cursor is moved to the selected position
5. The UI process can be terminated via the `TERMINATE_MOUSE_JUMP_SHARED_EVENT`
## Debugging
### Find My Mouse, Mouse Highlighter, and Mouse Pointer Crosshairs
- Debug by attaching to the Runner process directly
- Set breakpoints in the respective utility code files (e.g., `FindMyMouse.cpp`, `MouseHighlighter.cpp`, `InclusiveCrosshairs.cpp`)
- Call the respective utility by using the activation shortcut (e.g., double Ctrl press for Find My Mouse)
- During debugging, visual effects may appear glitchy due to the debugger's overhead
### Mouse Jump
- Start by debugging the Runner process
- Then attach the debugger to the MouseJumpUI process
- Note: Debugging MouseJumpUI directly is challenging as it requires the Runner's process ID as a parameter
## Known Issues
- Mouse Highlighter has a reported bug where the highlight color stays on after toggling opacity to 0
NewPlus is a PowerToys module that provides a context menu entry for creating new files directly from File Explorer. Unlike some other modules, NewPlus implements a different approach to context menu registration to avoid duplication issues in Windows 11.
## Context Menu Implementation
NewPlus implements two separate context menu handlers:
- Implemented as a sparse MSIX package for Windows 11's modern context menu
- Only registered and used on Windows 11
This implementation differs from some other modules like ImageResizer which register both handlers on Windows 11, resulting in duplicate menu entries. NewPlus uses selective registration to provide a cleaner user experience, though it can occasionally lead to issues if the Windows 11 handler fails to register properly.
## Project Structure
- **NewPlus.ShellExtension** - Windows 11 context menu handler implementation
- **NewPlus.ShellExtension.win10** - Windows 10 "old-style" context menu handler implementation
## Debugging NewPlus Context Menu Handlers
### Debugging the Windows 10 Handler
1. Update the registry to point to your debug build:
10. Set breakpoints in the code (e.g., in [shell_context_menu.cpp#L45](/src/modules/NewPlus/NewShellExtensionContextMenu/shell_context_menu.cpp#L45))
11. Right-click in File Explorer and attach the debugger to the `DllHost.exe` process (with NewPlus title) that loads when the context menu is invoked

12. Right-click again (quickly) after attaching the debugger to trigger the breakpoint
Note: The DllHost process loads the DLL only when the context menu is triggered and unloads after, making debugging challenging. For easier development, consider using logging or message boxes instead of breakpoints.
## Common Issues
- If the Windows 11 context menu entry doesn't appear, it may be due to:
- The package not being properly registered
- Explorer not being restarted after registration
- A signature issue with the MSIX package
- For development and testing, using the Windows 10 handler can be easier since it doesn't require signing.
PowerRename provides a powerful and flexible way to rename files in File Explorer. It is accessible through the Windows context menu and allows users to:
- Preview changes before applying them
- Use search and replace with regular expressions
- Filter items by type (files or folders)
- Apply case-sensitive or case-insensitive matching
PowerRename integrates with the Windows context menu following the [PowerToys Context Menu Handlers](../common/context-menus.md) pattern. It uses a dual registration approach to ensure compatibility with both Windows 10 and Windows 11.
### Registration Process
The context menu registration entry point is in `PowerRenameExt/dllmain.cpp::enable`, which registers:
- A traditional shell extension for Windows 10
- A sparse MSIX package for Windows 11 context menus
For more details on the implementation approach, see the [Dual Registration section](../common/context-menus.md#1-dual-registration-eg-imageresizer-powerrename) in the context menu documentation.
Contains the DLL entry point and module activation/deactivation code. The key function `RunPowerRename` is called when the context menu option is invoked, which launches the PowerRenameUI.
- Search/Replace input fields with x:Bind to `SearchMRU`/`ReplaceMRU` collections
- Preview list showing original and new filenames
- Settings panel for configuring rename options
- Event handling for `SearchReplaceChanged` to update the preview in real-time
## Debugging
### Debugging the Context Menu
See the [Debugging Context Menu Handlers](../common/context-menus.md#debugging-context-menu-handlers) section for general guidance on debugging PowerToys context menu extensions.
### Debugging the UI
To debug the PowerRename UI:
1. Add file paths manually in `\src\modules\powerrename\PowerRenameUILib\PowerRenameXAML\App.xaml.cpp`
2. Set the PowerRenameUI project as the startup project
3. Run in debug mode to test with the manually specified files
### Common Issues
- Context menu not appearing: Ensure the extension is properly registered and Explorer has been restarted
- UI not launching: Check Event Viewer for errors related to WinUI 3 application activation
- Rename operations failing: Verify file permissions and check for locked files
Quick Accent (formerly known as Power Accent) is a PowerToys module that allows users to quickly insert accented characters by holding a key and pressing an activation key (like the Space key or arrow keys). For example, holding 'a' might display options like 'à', 'á', 'â', etc. This tool enhances productivity by streamlining the input of special characters without the need to memorize keyboard shortcuts.
## Architecture
The Quick Accent module consists of four main components:
```
poweraccent/
├── PowerAccent.Core/ # Core component containing Language Sets
├── PowerAccent.UI/ # The character selector UI
├── PowerAccentKeyboardService/ # Keyboard Hook
└── PowerAccentModuleInterface/ # DLL interface
```
### Module Interface (PowerAccentModuleInterface)
The Module Interface, implemented in `PowerAccentModuleInterface/dllmain.cpp`, is responsible for:
- Handling communication between PowerToys Runner and the PowerAccent process
- Launching and terminating the PowerToys.PowerAccent.exe process
### Core Logic (PowerAccent.Core)
The Core component contains:
- Main accent character logic
- Keyboard input detection
- Character mappings for different languages
- Management of language sets and special characters (currency, math symbols, etc.)
- Usage statistics for frequently used characters
### UI Layer (PowerAccent.UI)
The UI component is responsible for:
- Displaying the toolbar with accent options
- Handling user selection of accented characters
- Managing the visual positioning of the toolbar
### Keyboard Service (PowerAccentKeyboardService)
This component:
- Implements keyboard hooks to detect key presses
- Manages the trigger mechanism for displaying the accent toolbar
- Handles keyboard input processing
## Implementation Details
### Activation Mechanism
The Quick Accent is activated when:
1. A user presses and holds a character key (e.g., 'a')
2. User presses the trigger key
3. After a brief delay (around 300ms per setting), the accent toolbar appears
4. The user can select an accented variant using the trigger key
5. Upon releasing the keys, the selected accented character is inserted
### Character Sets
The module includes multiple language-specific character sets and special character sets:
- Various language sets for different alphabets and writing systems
- Special character sets (currency symbols, mathematical notations, etc.)
- These sets are defined in the core component and can be extended
### Known Behaviors
- The module has a specific timing mechanism for activation that users have become accustomed to. Initially, this was considered a bug (where the toolbar would still appear even after quickly tapping and releasing keys), but it has been maintained as expected behavior since users rely on it.
- Multiple rapid key presses can trigger multiple background tasks.
## Future Considerations
- Potential refinements to the activation timing mechanism
- Additional language and special character sets
- Improved UI positioning in different application contexts
## Debugging
To debug the Quick Accent module via **runner** approach, follow these steps:
0. Get familiar with the overall [Debugging Process](../development/debugging.md) for PowerToys.
1.**Build** the entire PowerToys solution in Visual Studio
2. Navigate to the **PowerAccent** folder in Solution Explorer
3. Open the file you want to debug and set **breakpoints** at the relevant locations
4. Find the **runner** project in the root of the solution
5. Right-click on the **runner** project and select "*Set as Startup Project*"
6. Start debugging by pressing `F5` or clicking the "*Start*" button
7. When the PowerToys Runner launches, **enable** the Quick Accent module in the UI
8. Use the Visual Studio Debug menu or press `Ctrl+Alt+P` to open "*Reattach to Process*"
9. Find and select "**PowerToys.PowerAccent.exe**" in the process list
10. Trigger the action in Quick Accent that should hit your breakpoint
11. Verify that the debugger breaks at your breakpoint and you can inspect variables and step through code
This process allows you to debug the Quick Accent module while it's running as part of the full PowerToys application.
### Alternative Debugging Approach
To directly debug the Quick Accent UI component:
0. Get familiar with the overall [Debugging Process](../development/debugging.md) for PowerToys.
1.**Build** the entire PowerToys solution in Visual Studio
2. Navigate to the **PowerAccent** folder in Solution Explorer
3. Open the file you want to debug and set **breakpoints** at the relevant locations
4. Right-click on the **PowerAccent.UI** project and select "*Set as Startup Project*"
5. Start debugging by pressing `F5` or clicking the "*Start*" button
6. Verify that the debugger breaks at your breakpoint and you can inspect variables and step through code
**Known issue**: You may encounter approximately 78 errors during the start of debugging.<br>
**Solution**: If you encounter errors, right-click on the **PowerAccent** folder in Solution Explorer and select "*Rebuild*". After rebuilding, start debugging again.
Registry Preview simplifies the process of visualizing and editing complex Windows Registry files. It provides a powerful interface to preview, edit, and write changes to the Windows Registry. The module leverages the [Monaco Editor](../common/monaco-editor.md) to provide features like syntax highlighting and line numbering for registry files.
## Technical Architecture
Registry Preview is built using WinUI 3 with the [Monaco Editor](../common/monaco-editor.md) embedded for text editing capabilities. Monaco was originally designed for web environments but has been integrated into this desktop application to leverage its powerful editing features.
The module consists of several key components:
1.**Main Windows Interface** - Handles the UI interactions, window messaging, and resource loading
2.**Monaco Editor Integration** - Embeds the Monaco web-based editor into WinUI 3 (see [Monaco Editor documentation](../common/monaco-editor.md) for details)
3.**Registry Parser** - Parses registry files and builds a tree structure for visualization
4.**Editor Control** - Manages the editing capabilities and syntax highlighting
## Code Structure
The Registry Preview module is organized into the following projects:
- **RegistryPreview** - Main window implementation, including Windows message handling, resource loading, and service injection
- **RegistryPreviewUILib** - UI implementation details and backend logic
- **RegistryPreviewExt** - Project configuration and setup
- **RegistryPreview.FuzzTests** - Fuzzing tests for the module
Key files and components:
1.**MonacoEditorControl** - Handles the embedding of [Monaco](../common/monaco-editor.md) into WinUI 3 and sets up the WebView container
2.**MainWindow** - Manages all event handling in one place
3.**Utilities** - Contains shared helper methods and utility classes
## Main Functions
- **MonacoEditorControl**: Controls editing in Monaco
- **GetRuntimeMonacoDirectory**: Gets the current directory path
- **OpenRegistryFile**: Opens and processes a registry file (first-time open)
- **RefreshRegistryFile**: Re-opens and processes an already opened file
- **ParseRegistryFile**: Parses text from the editor
- **AddTextToTree**: Creates TreeView nodes from registry keys
- **ShowMessageBox**: Wrapper method for displaying message boxes
## Debugging Registry Preview
### Setup Debugging Environment
1. Set the PowerToys Runner as the parent process
2. Set the RegistryPreviewUILib project as the child process for debugging
3. Use the PowerToys Development Utility tool to configure debugging
### Debugging Tips
1. The main application logic is in the RegistryPreviewUILib project
2. Monaco-related issues may require debugging the WebView component (see [Monaco Editor documentation](../common/monaco-editor.md) for details)
3. For parsing issues, add breakpoints in the ParseRegistryFile method
4. UI issues are typically handled in the main RegistryPreview project
## UI Automation
Currently, Registry Preview does not have UI automation tests implemented. This is a potential area for future development.
## Recent Updates
Registry Preview has received community contributions, including:
- UI improvements
- New buttons and functionality
- Data preview enhancements
- Save button improvements
## Future Considerations
- Adding UI automation tests
- Further [Monaco editor](../common/monaco-editor.md) updates
Screen Ruler (project name: MeasureTool or Measure 2) is a PowerToys module that allows users to measure pixel distances and detect color boundaries on the screen. The tool renders an overlay UI using DirectX and provides several measurement utilities.
## Features
- **Bounce Utility**: Measure a rectangular zone by dragging with a left click
- **Spacing Tool**: Measure the length of a line with the same color with the same pixel value both horizontally and vertically
- **Horizontal Spacing**: Measure the line with the same color in the horizontal direction
- **Vertical Spacing**: Measure the line with the same color in the vertical direction
## Architecture & Implementation
The Screen Ruler module consists of several components:
### MeasureToolModuleInterface
- **Dllmain.cpp**: Provides functionality to start and stop the Measure Tool process based on hotkey events, manage settings, and handle events.
### MeasureToolUI
- **App.xaml.cs**: Main entrance of the app. Initializes MeasureToolCore and activates a new main window.
- **MainWindow.xaml.cs**: Sets properties and behaviors for the window, and handles user click interactions.
- **NativeMethods.cs**: Interacts with the Windows API to manipulate window properties, such as positioning and sizing.
- **Settings.cs**: Gets the default measure style from settings.
### PowerToys.MeasureToolCore
- **PowerToys.MeasureToolCore**: Handles initialization, state management, and starts the measure tool and bounds tool.
- **BGRATextureView.h**: Manages and interacts with BGRA textures in a Direct3D 11 context.
- **Measurement.cpp**: Defines a Measurement struct that represents a rectangular measurement area, including methods for converting and printing measurement details in various units.
- **Clipboard.cpp**: Copies measurement data to the clipboard.
- **D2DState.cpp**: Manages Direct2D rendering state and draws text boxes.
- **DxgiAPI.cpp**: Creates and manages Direct3D and Direct2D devices.
- **EdgeDetection.cpp**: Detects edges in a BGRA texture.
- **OverlayUI.cpp**: Creates and manages overlay windows for tools like MeasureTool and BoundsTool.
- **BoundsToolOverlayUI.cpp**: UI implementation for bounds feature. Handles mouse and touch events to draw measurement rectangles on the screen and display their pixels.
- **MeasureToolOverlayUI.cpp**: UI implementation for measure feature. Draws measurement lines on the screen and displays their pixels.
- **ScreenCapturing.cpp**: Continuously captures the screen, detects edges, and updates the measurement state for real-time drawing of measurement lines.
- **PerGlyphOpacityTextRender.cpp**: Renders text with varying opacity on a Direct2D render target.
## Building & Debugging
### Building
1. Open PowerToys.sln in Visual Studio
2. In the Solutions Configuration drop-down menu, select Release or Debug
3. From the Build menu, choose Build Solution
4. The executable app for Screen Ruler is named PowerToys.MeasureToolUI.exe
### Debugging
1. Right-click the project MeasureToolUI and click 'Set as Startup Project'
2. Right-click the project MeasureToolUI and click 'Debug'
## Known Issues
There are several open bugs for the Screen Ruler module, most of which are related to crashing issues. These can be found in the [PowerToys issues list](https://github.com/microsoft/PowerToys/issues?q=is%3Aissue%20state%3Aopen%20Screen%20ruler%20type%3ABug).
Shortcut Guide is a PowerToy that displays an overlay of available keyboard shortcuts when the Windows key is pressed and held. It provides a visual reference for Windows key combinations, helping users discover and utilize built-in Windows shortcuts.
## Usage
- Press and hold the Windows key to display the overlay of available shortcuts
- Press the hotkey again to dismiss the overlay
- The overlay displays Windows shortcuts with their corresponding actions
## Build and Debug Instructions
### Build
1. Open PowerToys.sln in Visual Studio
2. Select Release or Debug in the Solutions Configuration drop-down menu
3. From the Build menu, choose Build Solution
4. The executable is named PowerToys.ShortcutGuide.exe
### Debug
1. Right-click the ShortcutGuide project and select 'Set as Startup Project'
2. Right-click the project again and select 'Debug'
Contains DLL boilerplate code. Implements the PowertoyModuleIface, including enable/disable functionality and GPO policy handling. Captures hotkey events and starts the PowerToys.ShortcutGuide.exe process to display the shortcut guide window.
Contains the module interface code. It initializes the settings values and the keyboard event listener.
Contains the module interface code. It initializes the settings values and the keyboard event listener. Defines the OverlayWindow class, which manages the overall logic and event handling for the PowerToys Shortcut Guide.
Contains the code for loading the SVGs, creating and rendering of the overlay window.
Contains the code for loading the SVGs, creating and rendering of the overlay window. Manages and displays overlay windows with SVG graphics through two main classes:
- D2DOverlaySVG: Handles loading, resizing, and manipulation of SVG graphics
- D2DOverlayWindow: Manages the display and behavior of the overlay window
State machine that handles the keyboard events. It’s responsible for deciding when to show the overlay, when to suppress the Start menu (if the overlay is displayed long enough), etc.
State machine that handles the keyboard events. It's responsible for deciding when to show the overlay, when to suppress the Start menu (if the overlay is displayed long enough), etc. Handles state transitions and synchronization to ensure the overlay is shown or hidden appropriately based on user interactions.
Handles the timing and interpolation of animations. Calculates the current value of an animation based on elapsed time and a specified easing function.
Waits for a named event and executes a specified action when the event is triggered. Uses a separate thread to handle event waiting and action execution.
The entry point for the PowerToys Shortcut Guide application. Handles initialization, ensures single instance execution, manages parent process termination, creates and displays the overlay window, and runs the main event loop.
## Features and Limitations
- The overlay displays Windows shortcuts (Windows key combinations)
- The module supports localization, but only for the Windows controls on the left side of the overlay
- It's currently rated as a P3 (lower priority) module
## Future Development
A community-contributed version 2 is in development that will support:
- Application-specific shortcuts based on the active application
- Additional shortcuts beyond Windows key combinations
Text Extractor is a PowerToys utility that enables users to extract and copy text from anywhere on the screen, including inside images and videos. The module uses Optical Character Recognition (OCR) technology to recognize text in visual content. This module is based on Joe Finney's Text Grab.
## How it works
Text Extractor captures the screen content and uses OCR to identify and extract text from the selected area. Users can select a region of the screen, and Text Extractor will convert any visible text in that region into copyable text.
## Architecture
### Components
- **EventMonitor**: Handles the `ShowPowerOCRSharedEvent` which triggers the OCR functionality
- **OCROverlay**: The main UI component that provides:
- Language selection for OCR processing
- Canvas for selecting the screen area to extract text from
- **Screen Capture**: Uses `CopyFromScreen` to capture the screen content as the overlay background image
### Activation Methods
- **Global Shortcut**: Activates Text Extractor through a keyboard shortcut
- **LaunchOCROverlayOnEveryScreen**: Functionality to display the OCR overlay across multiple monitors
## Technical Implementation
Text Extractor is implemented using Windows Presentation Foundation (WPF) technology, which provides the UI framework for the selection canvas and other interface elements.
## User Experience
When activated, Text Extractor displays an overlay on the screen that allows users to select an area containing text. Once selected, the OCR engine processes the image and extracts any text found, which can then be copied to the clipboard.
ZoomIt is a screen zoom and annotation tool originally from Microsoft's Sysinternals suite. It allows users to:
- Zoom in on specific areas of the screen
- Draw and annotate on the screen while zoomed in
- Use a timer for presentations or breaks
- Pan and move while zoomed in
- Record screen activity with audio
ZoomIt runs in the background and is activated via customizable hotkeys.
## Special Integration Considerations
Unlike other PowerToys modules, ZoomIt has some unique integration aspects:
1.**Registry-based Settings**: ZoomIt uses registry settings instead of JSON files (which is the standard for other PowerToys modules). This was required to maintain compatibility with the standalone Sysinternals version.
2.**Dual Source of Truth**: The PowerToys repository serves as the source of truth for both the PowerToys version and the standalone Sysinternals version, with build flags to differentiate between them.
3.**Settings Integration**: A special WinRT/C++ interop library was developed to bridge between PowerToys' JSON-based settings system and ZoomIt's registry-based settings.
## Technical Architecture
The ZoomIt module consists of the following components:
1.**ZoomIt Executable** (`PowerToys.ZoomIt.exe`): The main ZoomIt application that provides the zooming and annotation functionality.
2.**Module Interface** (`PowerToys.ZoomItModuleInterface.dll`): Implements the PowerToys module interface to integrate with the PowerToys runner.
3.**Settings Interop** (`ZoomItSettingsInterop`): A WinRT/C++ interop library that enables communication between PowerToys settings and ZoomIt's registry settings.
│ └── ZoomItSettingsInterop/ # WinRT/C++ interop for settings
├── settings-ui/
│ └── Settings.UI/
│ ├── SettingsXAML/
│ │ └── Views/
│ │ └── ZoomItPage.xaml # ZoomIt settings page UI
│ └── ViewModels/
│ └── ZoomItViewModel.cs # ZoomIt settings view model
└── common/
└── sysinternals/ # Common code from Sysinternals
```
## Settings Management
ZoomIt's settings are stored in the Windows registry instead of JSON files to maintain compatibility with the standalone version. The settings include:
- Hotkey combinations for different modes (zoom, draw, etc.)
- Drawing options (colors, line thickness, etc.)
- Font settings for text annotations
- Microphone selection for recording
- Custom file paths for demo mode and break backgrounds
The `ZoomItSettingsInterop` library handles:
1. Loading settings from registry and converting to JSON for PowerToys settings UI
2. Saving changes from the settings UI back to the registry
3. Notifying the ZoomIt application when settings change

## Integration Steps
The integration of ZoomIt into PowerToys involved these key steps:
1.**Code Migration**:
- Moving code from the Sysinternals ZoomIt repository to `src/modules/ZoomIt/ZoomIt`
- Adding required common libraries to `src/common/sysinternals`
- Sanitizing code for open source (removing private APIs, undocumented details, etc.)
- Ensuring no private APIs (validated through APIScan)
- Removing references to undocumented implementation details, constants, and names
- Standardizing dependencies with other PowerToys utilities
2.**Module Interface Implementation**:
- Creating the PowerToys module interface
- Adding process management (start/terminate)
- Implementing event-based communication for settings updates
- Adding named events for communication between PowerToys and ZoomIt
3.**Settings Integration**:
- Extracting ZoomIt settings code to a shareable component
- Creating a WinRT/C++ interop library for registry-JSON conversion
- Implementing all settings UI controls in PowerToys settings
- Building `ZoomItSettingsInterop` as a bridge between registry and JSON settings
4.**PowerToys Integration**:
- Adding ZoomIt to the PowerToys runner
- Adding GPO rules for ZoomIt
- Implementing telemetry and logging
- Creating OOBE (out-of-box experience) page with animated tutorial
- Adding ZoomIt to process termination list for proper cleanup
- Adding telemetry events documentation
5.**UI/UX Adjustments**:
- Redirecting ZoomIt's settings UI to PowerToys settings
- Handling hotkey conflicts with warning notifications
- Modifying tray icon behavior
- Removing original ZoomIt options menu entries
- Adding Sysinternals attribution on the settings page
6.**Build System Updates**:
- Adding ZoomIt to the PowerToys solution
- Implementing build flags for standalone vs. PowerToys versions
- Adding signing for new binaries
- Fixing analyzer errors and code quality issues
## Debug Instructions
1. Build the entire PowerToys solution at least once.
2. Set `runner` as the startup project and start debugging.
3. Once the PowerToys Settings app is running and ensure ZoomIt is activated.
4. Set `ZoomIt` as the startup project in Visual Studio.
5. Press `Ctrl + Alt + P` and attach ZoomIt to the process.
6. You should now be able to set breakpoints and step through the code.
## Special Implementation Details
### Font Selection
ZoomIt requires storing font information as a binary LOGFONT structure in the registry. This required special handling:
- Creating P/Invoke declarations for Windows font APIs
- Base64 encoding the binary data for transfer through JSON
- Using native Windows dialogs for font selection
### Hotkey Management
ZoomIt registers hotkeys through the Windows RegisterHotKey API. Special handling was needed to:
- Detect and notify about hotkey conflicts
- Update hotkeys when settings change
- Support modifier keys
### Process Communication
Communication between PowerToys and ZoomIt uses:
- Command-line arguments to pass PowerToys process ID
- Named events for signaling settings changes and exit requests
- Windows messages for internal ZoomIt state management
## Implementation Challenges
Several challenges were encountered during ZoomIt integration:
1.**First-Run Behavior**:
- Font loading crashed when no ZoomIt data existed in registry
- Hotkeys weren't registered on first run with no existing data
- Implemented safeguards to handle missing registry data
2.**Settings Synchronization**:
- Modifier keys for shortcuts weren't correctly updated when settings changed
- Implemented proper event notification for settings changes
- Added hotkey conflict detection and warnings
3.**File Interaction**:
- ZoomIt file pickers changed the working directory of the Settings project
- Fixed to maintain proper directory context
4.**Drawing Issues**:
- Color settings lacking opacity caused drawing functionality to fail
- Removed internal state settings that weren't truly editable
5.**Dual-Build Support**:
- Added build flags to support both PowerToys and standalone Sysinternals versions
- Implemented different executable properties based on build target
## Source Code Management
The PowerToys repository serves as the source of truth for both PowerToys and Sysinternals standalone versions of ZoomIt. Key repositories involved:
- Common library repo: `https://dev.azure.com/sysinternals/Tools/_git/Common`
The integration process can be tracked through [PR #35880](https://github.com/microsoft/PowerToys/pull/35880) which contains the complete history of changes required to properly integrate ZoomIt.
Group Policy Objects (GPOs) allow system administrators to control PowerToys settings across an organization. This document describes how GPOs are implemented in PowerToys.
## GPO Overview
GPO policies allow system administrators to control PowerToys settings. PowerToys ships GPO files as part of the release zip, not installed directly.
## GPO File Structure
### ADMX File
- Contains policy definitions
- Defines which versions support each policy
- Sets up folder structure
- Defines each policy with:
- Name
- Class (user scope or machine scope)
- Description
- Registry location where policy is stored
- Enabled/disabled values
### ADML File
- Contains localized strings for the ADMX file
- Contains revision number that must be updated when changes are made
- Stores strings for:
- Folder names
- Version definitions
- Policy descriptions and titles
- Currently only ships English US version (no localization story yet)
## Installation Process
- Files need to be placed in: `C:\Windows\PolicyDefinitions\`
- ADMX file goes in the root folder
- ADML file goes in the language subfolder (e.g., en-US)
- After installation, policies appear in the Group Policy Editor (gpedit.msc)
## Registry Implementation
- Policies are stored as registry values
- Location: `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PowerToys` or `HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\PowerToys`
- Machine scope takes precedence over user scope
- Policy states:
- Enabled: Registry value set to 1
- Disabled: Registry value set to 0
- Not Configured: Registry value does not exist
## Code Integration
### Common Files
- Policy keys defined in `common\utils\GPO.h`
- Contains functions to read registry values and get configured values
- WinRT C++ adapter created for C# applications to access GPO settings
### WPF Applications
- WPF applications cannot directly load WinRT C++ projects
- Additional library created to allow WPF applications to access GPO values
### Module Interface
- Each module must implement policy checking in its interface
- Runner checks this to determine if module should be started or not
## UI Implementation
- When a policy disables a utility:
- UI is locked (cannot be enabled)
- Settings page shows a lock icon
- Dashboard hides the module button
- If user tries to start the executable directly, it exits and logs a message
## Types of GPO Policies
### Basic Module Enable/Disable Policy
- Most common type
- Controls whether a module can be enabled or disabled
- Shared description text for these policies
### Configuration Policies
- Example: Run at startup setting
- Controls specific settings rather than enabling/disabling modules
- Custom description text explaining what happens when enabled/disabled/not configured
### Machine-Scope Only Policies
- Example: Mouse Without Borders service mode
- Only makes sense at machine level (not user level)
- Restricts functionality that requires elevated permissions
## Steps to Add a New Policy
1. Update ADMX file:
- Increase revision number
- Add supported version definition
- Define the policy with registry location
2. Update ADML file:
- Increase revision number
- Add strings for version, title, description
3. Update code:
- Add to GPO.h
- Add to GPO wrapper for C# access
- Update module interface
- Modify settings UI to show lock when policy applied
- Add checks in executable to prevent direct launching
Welcome to the PowerToys developer documentation. This documentation provides information for developers who want to contribute to PowerToys or understand how it works.
## Core Architecture
- [Architecture Overview](core/architecture.md) - Overview of the PowerToys architecture and module interface
- [Runner and System tray](core/runner.md) - Details about the PowerToys Runner process
- [Settings](core/settings/readme.md) - Documentation on the settings system
- [Installer](core/installer.md) - Information about the PowerToys installer
- [Modules](modules/readme.md) - Documentation for individual PowerToys modules
## Common Components
- [Context Menu Handlers](common/context-menus.md) - How PowerToys implements and registers Explorer context menu handlers
- [Monaco Editor](common/monaco-editor.md) - How PowerToys uses the Monaco code editor component across modules
- [Logging and Telemetry](development/logging.md) - How to use logging and telemetry
- [Localization](development/localization.md) - How to support multiple languages
## Development Guidelines
- [Coding Guidelines](development/guidelines.md) - Development guidelines and best practices
- [Coding Style](development/style.md) - Code formatting and style conventions
- [UI Testing](development/ui-tests.md) - How to write UI tests for PowerToys
- [Debugging](development/debugging.md) - Techniques for debugging PowerToys
## Tools
- [Tools Overview](tools/readme.md) - Overview of tools in PowerToys
- [Build Tools](tools/build-tools.md) - Tools that help building PowerToys
- [Bug Report Tool](tools/bug-report-tool.md) - Tool for collecting logs and system information
- [Debugging Tools](tools/debugging-tools.md) - Specialized tools for debugging
- [Fuzzing Testing](tools/fuzzingtesting.md) - How to implement and run fuzz testing for PowerToys modules
## Processes
- [Release Process](processes/release-process.md) - How PowerToys releases are prepared and published
- [Update Process](processes/update-process.md) - How PowerToys updates work
- [GPO Implementation](processes/gpo.md) - Group Policy Objects implementation details
## Fork, Clone, Branch and Create your PR
@@ -14,7 +52,7 @@ Once you've discussed your proposed feature/fix/etc. with a team member, and an
## Rules
- **Follow the pattern of what you already see in the code.**
- [Coding style](style.md).
- [Coding style](development/style.md).
- Try to package new functionality/components into libraries that have nicely defined interfaces.
- Package new functionality into classes or refactor existing functionality into a class as you extend the code.
- When adding new classes/methods/changing existing code, add new unit tests or update the existing tests.
@@ -76,89 +114,9 @@ The installer can only be compiled in `Release` mode; steps 1 and 2 must be perf
1. Compile `PowerToysSetup.sln` Path from root: `installer\PowerToysSetup.sln` (details listed below)
### Prerequisites for building the MSI installer
1. Install the [WiX Toolset Visual Studio 2022 Extension](https://marketplace.visualstudio.com/items?itemName=WixToolset.WixToolsetVisualStudio2022Extension).
1. Install the [WiX Toolset build tools](https://github.com/wixtoolset/wix3/releases/tag/wix3141rtm). (installer [direct link](https://github.com/wixtoolset/wix3/releases/download/wix3141rtm/wix314.exe))
1. Download [WiX binaries](https://github.com/wixtoolset/wix3/releases/download/wix3141rtm/wix314-binaries.zip) and extract `wix.targets` to `C:\Program Files (x86)\WiX Toolset v3.14`.
### Building prerequisite projects
#### From the command line
1. From the start menu, open a `Developer Command Prompt for VS 2022`
If you prefer, you can alternatively build prerequisite projects for the installer using the Visual Studio UI.
1. Open `tools\BugReportTool\BugReportTool.sln`
1. In Visual Studio, in the `Solutions Configuration` drop-down menu select `Release`
1. From the `Build` menu, choose `Build Solution`.
1. Open `tools\StylesReportTool\StylesReportTool.sln`
1. In Visual Studio, in the `Solutions Configuration` drop-down menu select `Release`
1. From the `Build` menu, choose `Build Solution`.
### Locally compiling the installer
1. Open `installer\PowerToysSetup.sln`
1. In Visual Studio, in the `Solutions Configuration` drop-down menu select `Release`
1. From the `Build` menu choose `Build Solution`.
The resulting `PowerToysSetup.msi` installer will be available in the `installer\PowerToysSetup\x64\Release\` folder.
#### Supported arguments for the .EXE Bootstrapper installer
Head over to the wiki to see the [full list of supported installer arguments][installerArgWiki].
## Debugging
To debug the PowerToys application in Visual Studio, set the `runner` project as your start-up project, then start the debugger.
Some PowerToys modules must be run with the highest permission level if the current user is a member of the Administrators group. The highest permission level is required to be able to perform some actions when an elevated application (e.g. Task Manager) is in the foreground or is the target of an action. Without elevated privileges some PowerToys modules will still work but with some limitations:
- The `FancyZones` module will not be able to move an elevated window to a zone.
- The `Shortcut Guide` module will not appear if the foreground window belongs to an elevated application.
Therefore, it is recommended to run Visual Studio with elevated privileges when debugging these scenarios. If you want to avoid running Visual Studio with elevated privileges and don't mind the limitations described above, you can do the following: open the `runner` project properties and navigate to the `Linker -> Manifest File` settings, edit the `UAC Execution Level` property and change it from `highestAvailable (level='highestAvailable')` to `asInvoker (/level='asInvoker').
See [Installer](core/installer.md) for more details on building and debugging the installer.
## How to create new PowerToys
See the instructions on [how to install the PowerToys Module project template](/tools/project_template). <br />
Specifications for the [PowerToys settings API](settingsv2/readme.md).
## Implementation details
### [`Runner`](runner.md)
The PowerToys Runner contains the project for the PowerToys.exe executable.
It's responsible for:
- Loading the individual PowerToys modules.
- Passing registered events to the PowerToys.
- Showing a system tray icon to manage the PowerToys.
- Bridging between the PowerToys modules and the Settings editor.

### [`Interface`](modules/interface.md)
The definition of the interface used by the [`runner`](/src/runner) to manage the PowerToys. All PowerToys must implement this interface.
### [`Common`](common.md)
The common lib, as the name suggests, contains code shared by multiple PowerToys components and modules, e.g. [json parsing](/src/common/utils/json.h) and [IPC primitives](/src/common/interop/two_way_pipe_message_ipc.h).
### [`Settings`](settingsv2/)
Settings v2 is our current settings implementation. Please head over to the dev docs that describe the current settings system.
Specifications for the [PowerToys settings API](core/settings/readme.md).
Contains the executable starting point, initialization code and the list of known PowerToys. All singletons are also initialized here at the start. Loads all the powertoys by scanning the `./modules` folder and `enable()`s those marked as enabled in `%LOCALAPPDATA%\Microsoft\PowerToys\settings.json` config. Then it runs [a message loop](https://learn.microsoft.com/windows/win32/winmsg/using-messages-and-message-queues) for the tray UI. Note that this message loop also [handles lowlevel_keyboard_hook events](https://github.com/microsoft/PowerToys/blob/1760af50c8803588cb575167baae0439af38a9c1/src/runner/lowlevel_keyboard_event.cpp#L24).
#### [`powertoy_module.h`](/src/runner/powertoy_module.h) and [`powertoy_module.cpp`](/src/runner/powertoy_module.cpp)
Contains code for initializing and managing the PowerToy modules. `PowertoyModule` is a RAII-style holder for the `PowertoyModuleIface` pointer, which we got by [invoking module DLL's `powertoy_create` function](https://github.com/microsoft/PowerToys/blob/1760af50c8803588cb575167baae0439af38a9c1/src/runner/powertoy_module.cpp#L13-L24).
#### [`tray_icon.cpp`](/src/runner/tray_icon.cpp)
Contains code for managing the PowerToys tray icon and its menu commands. Note that `dispatch_run_on_main_ui_thread` is used to
transfer received json message from the [Settings window](/doc/devdocs/settings.md) to the main thread, since we're communicating with it from [a dedicated thread](https://github.com/microsoft/PowerToys/blob/7357e40d3f54de51176efe54fda6d57028837b8c/src/runner/settings_window.cpp#L267-L271).
Contains code for starting the PowerToys settings window and communicating with it. Settings window is a separate process, so we're using [Windows pipes](https://learn.microsoft.com/windows/win32/ipc/pipes) as a transport for json messages.
Contains code to handle the automatic update checking, notification, and installation process for PowerToys.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.