Files
PowerToys/src/modules/powerrename/dll/dllmain.cpp

356 lines
9.7 KiB
C++
Raw Normal View History

#include "pch.h"
#include "Generated Files/resource.h"
#include "PowerRenameConstants.h"
#include "PowerRenameExt.h"
#include <interface/powertoy_module_interface.h>
#include <settings.h>
#include <trace.h>
#include <VersionHelpers.h>
#include <common/SettingsAPI/settings_objects.h>
#include <common/logger/logger.h>
#include <common/utils/logger_helper.h>
#include <common/utils/package.h>
#include <common/utils/process_path.h>
#include <common/utils/resources.h>
refactor: Replace WiX-based registration with conditional runtime registration for Win10 context menu modules (#41275) <!-- 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 WiX-based registration creates persistent Shell Extension entries that: 1. Load DLLs even when the module is disabled 2. Cause cross-OS version conflicts (Win11 loading Win10 extensions) ## Changes Made 1. Removed static Shell Extension registration from PowerToys installer 2. Modified modules to register Shell Extensions during Runner startup ### Modified Modules: - **PowerRename** (`src/modules/powerrename/dll/dllmain.cpp`) - **NewPlus** (`src/modules/NewPlus/NewShellExtensionContextMenu/powertoys_module.cpp`) - **ImageResizer** (`src/modules/imageresizer/dll/dllmain.cpp`) - **FileLocksmith** (`src/modules/FileLocksmith/FileLocksmithExt/PowerToysModule.cpp`) ## Known Migration Issue **Machine-level installer registry residue**: win10 with machine-level installers may have residual Shell Extension registry entries that persist with this change. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #40036 - [ ] **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 ## AI Summary This pull request refactors how shell extension registry keys are managed during installation and uninstallation for several PowerToys modules. The main change is moving registry key cleanup logic for context menu shell extensions (ImageResizer, FileLocksmith, PowerRename, NewPlus) from static installer definitions to new custom uninstall actions, ensuring more reliable removal and future extensibility. **Installer and Uninstall Refactoring** * Added new custom actions (`CleanImageResizerRuntimeRegistryCA`, `CleanFileLocksmithRuntimeRegistryCA`, `CleanPowerRenameRuntimeRegistryCA`, `CleanNewPlusRuntimeRegistryCA`) to programmatically clean up registry keys for each shell extension during uninstall, implemented in `CustomAction.cpp` and exported in `CustomAction.def`. [[1]](diffhunk://#diff-c502a81cdf8afa7a38f0f462709abcdbdfcc44beaa6227a1e64a26566c7e8876R1156-R1262) [[2]](diffhunk://#diff-f941d599be5fe41667eda00338af694c0f2e65709d497a66487402f13e408200R31-R34) * Registered these custom actions in `Product.wxs` and ensured they run before file removal during uninstall. [[1]](diffhunk://#diff-668b4388b55bb934d7ceccbfdd172f69257c9c607ca19cb9752d4a4940b69886R179-R190) [[2]](diffhunk://#diff-668b4388b55bb934d7ceccbfdd172f69257c9c607ca19cb9752d4a4940b69886R454-R482) **Removal of Static Registry Key Definitions** * Removed static registry key and component definitions for context menu shell extensions from their respective installer `.wxs` files (`FileLocksmith.wxs`, `ImageResizer.wxs`, `PowerRename.wxs`, `NewPlus.wxs`), relying on custom actions for cleanup instead. [[1]](diffhunk://#diff-7cf9797f8cb6609049763b3b830f6c4a7a02ba5705eb090f7e06fb9c270ca74fL17-L31) [[2]](diffhunk://#diff-7cf9797f8cb6609049763b3b830f6c4a7a02ba5705eb090f7e06fb9c270ca74fL41) [[3]](diffhunk://#diff-c6d00805ce9de0eb3f4d42874dccac17be62f36c35d57e8f863b928b5f955d3aL19-L83) [[4]](diffhunk://#diff-c6d00805ce9de0eb3f4d42874dccac17be62f36c35d57e8f863b928b5f955d3aL93) [[5]](diffhunk://#diff-d0d69eff3f2d7982679465972b7d3c46dd8006314fb28f0e3a2371e2d5ccedb0L21-L33) [[6]](diffhunk://#diff-d0d69eff3f2d7982679465972b7d3c46dd8006314fb28f0e3a2371e2d5ccedb0L43) [[7]](diffhunk://#diff-4fd109f66b896577cad2860a829617ca902b33551afaaa8840372035ade2d3f3L17-L32) [[8]](diffhunk://#diff-4fd109f66b896577cad2860a829617ca902b33551afaaa8840372035ade2d3f3L42) **Project File Update** * Added `shell_ext_registration.h` to the solution file, possibly for future shell extension registration logic. These changes improve uninstall reliability and centralize registry cleanup logic, making future maintenance and extension of shell extension registration much simpler. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-08-21 18:10:30 +08:00
#include "RuntimeRegistration.h"
#include <atomic>
std::atomic<DWORD> g_dwModuleRefCount = 0;
HINSTANCE g_hInst = 0;
class CPowerRenameClassFactory : public IClassFactory
{
public:
CPowerRenameClassFactory(_In_ REFCLSID clsid) :
m_refCount(1),
m_clsid(clsid)
{
ModuleAddRef();
}
// IUnknown methods
IFACEMETHODIMP QueryInterface(_In_ REFIID riid, _COM_Outptr_ void** ppv)
{
2019-12-20 16:59:20 +03:00
static const QITAB qit[] = {
QITABENT(CPowerRenameClassFactory, IClassFactory),
{ 0 }
};
return QISearch(this, qit, riid, ppv);
}
2019-12-20 16:59:20 +03:00
IFACEMETHODIMP_(ULONG)
AddRef()
{
return ++m_refCount;
}
2019-12-20 16:59:20 +03:00
IFACEMETHODIMP_(ULONG)
Release()
{
LONG refCount = --m_refCount;
if (refCount == 0)
{
delete this;
}
return refCount;
}
// IClassFactory methods
IFACEMETHODIMP CreateInstance(_In_opt_ IUnknown* punkOuter, _In_ REFIID riid, _Outptr_ void** ppv)
{
*ppv = NULL;
HRESULT hr;
if (punkOuter)
{
hr = CLASS_E_NOAGGREGATION;
}
else if (m_clsid == CLSID_PowerRenameMenu)
{
hr = CPowerRenameMenu::s_CreateInstance(punkOuter, riid, ppv);
}
else
{
hr = CLASS_E_CLASSNOTAVAILABLE;
}
return hr;
}
IFACEMETHODIMP LockServer(BOOL bLock)
{
if (bLock)
{
ModuleAddRef();
}
else
{
ModuleRelease();
}
return S_OK;
}
private:
~CPowerRenameClassFactory()
{
ModuleRelease();
}
std::atomic<long> m_refCount;
CLSID m_clsid;
};
BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, void*)
{
switch (dwReason)
{
case DLL_PROCESS_ATTACH:
g_hInst = hInstance;
Trace::RegisterProvider();
break;
case DLL_PROCESS_DETACH:
Trace::UnregisterProvider();
break;
}
return TRUE;
}
//
// Checks if there are any external references to this module
//
STDAPI DllCanUnloadNow(void)
{
return (g_dwModuleRefCount == 0) ? S_OK : S_FALSE;
}
//
// DLL export for creating COM objects
//
2019-12-20 16:59:20 +03:00
STDAPI DllGetClassObject(_In_ REFCLSID clsid, _In_ REFIID riid, _Outptr_ void** ppv)
{
HRESULT hr = E_FAIL;
*ppv = NULL;
2019-12-20 16:59:20 +03:00
CPowerRenameClassFactory* pClassFactory = new CPowerRenameClassFactory(clsid);
hr = pClassFactory->QueryInterface(riid, ppv);
pClassFactory->Release();
return hr;
}
STDAPI DllRegisterServer()
{
return S_OK;
}
STDAPI DllUnregisterServer()
{
return S_OK;
}
void ModuleAddRef()
{
g_dwModuleRefCount++;
}
void ModuleRelease()
{
g_dwModuleRefCount--;
}
class PowerRenameModule : public PowertoyModuleIface
{
private:
// Enabled by default
bool m_enabled = false;
std::wstring app_name;
//contains the non localized key of the powertoy
std::wstring app_key;
fix: Context menu registry entries are not cleaned up when disabled via GPO (#41411) <!-- 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 context menu runtime registration wasn't properly cleaned up when GPO (Group Policy Object) policies disabled the module. The problem occurred because the module constructor didn't consider GPO policies when determining its initial enabled state. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #41387 - [ ] **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 This pull request refactors how context menu registration and unregistration are handled across several PowerToys modules. The main improvement is the introduction of a new `UpdateRegistration` helper method in each module, which centralizes and simplifies the logic for registering or unregistering context menus when the module is enabled or disabled. This reduces code duplication and ensures consistent behavior. **Context menu registration logic refactor:** * Added a private `UpdateRegistration` method to each of the following modules to handle context menu registration and unregistration based on the enabled state: - `FileLocksmithModule` in `PowerToysModule.cpp` - `NewModule` in `powertoys_module.cpp` - `ImageResizerModule` in `dllmain.cpp` - `PowerRenameModule` in `dllmain.cpp` * Replaced direct calls to registration/unregistration functions in `enable`, `disable`, and `init_settings` methods with calls to the new `UpdateRegistration` method in all affected modules, ensuring consistent and centralized handling [[1]](diffhunk://#diff-256ed936dafec1bf6ff17849b4797dd276f5b07bebe2e483bc1580c8f06e92d9L91-R122) [[2]](diffhunk://#diff-256ed936dafec1bf6ff17849b4797dd276f5b07bebe2e483bc1580c8f06e92d9R155) [[3]](diffhunk://#diff-4a3942d548f3daec02a833983ed9b2b69f75e2cd1b74a8ce1b874f3fd33fde55L101-R125) [[4]](diffhunk://#diff-4a3942d548f3daec02a833983ed9b2b69f75e2cd1b74a8ce1b874f3fd33fde55L153-R177) [[5]](diffhunk://#diff-0c0a89e812ff4625d165417da14f1c3f203e5ac7907555ae4fde122f3dddcf7aL115-L130) [[6]](diffhunk://#diff-34581ec47c37b0d2e1d9b59696225c47342930694e732db06cbdf653ceb2c2d7L205-R234) [[7]](diffhunk://#diff-34581ec47c37b0d2e1d9b59696225c47342930694e732db06cbdf653ceb2c2d7R334). These changes improve maintainability and reduce the risk of inconsistent registration behavior across modules. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-08-27 19:16:55 +08:00
// Update registration based on enabled state
void UpdateRegistration(bool enabled)
{
if (enabled)
{
#if defined(ENABLE_REGISTRATION) || defined(NDEBUG)
PowerRenameRuntimeRegistration::EnsureRegistered();
Logger::info(L"PowerRename context menu registered");
#endif
}
else
{
#if defined(ENABLE_REGISTRATION) || defined(NDEBUG)
PowerRenameRuntimeRegistration::Unregister();
Logger::info(L"PowerRename context menu unregistered");
#endif
}
}
public:
// Return the localized display name of the powertoy
virtual PCWSTR get_name() override
{
return app_name.c_str();
}
// Return the non localized key of the powertoy, this will be cached by the runner
virtual const wchar_t* get_key() override
{
return app_key.c_str();
}
2022-10-26 14:02:31 +01:00
// Return the configured status for the gpo policy for the module
virtual powertoys_gpo::gpo_rule_configured_t gpo_policy_enabled_configuration() override
{
return powertoys_gpo::getConfiguredPowerRenameEnabledValue();
}
// Enable the powertoy
virtual void enable()
{
Logger::info(L"PowerRename enabled");
m_enabled = true;
if (package::IsWin11OrGreater())
{
std::wstring path = get_module_folderpath(g_hInst);
std::wstring packageUri = path + L"\\PowerRenameContextMenuPackage.msix";
Add the Command Palette module (#37908) Windows Command Palette ("CmdPal") is the next iteration of PowerToys Run. With extensibility at its core, the Command Palette is your one-stop launcher to start _anything_. By default, CmdPal is bound to <kbd>Win+Alt+Space</kbd>. ![cmdpal-pr-002](https://github.com/user-attachments/assets/5077ec04-1009-478a-92d6-0a30989d44ac) ![cmdpal-pr-003](https://github.com/user-attachments/assets/63b4762a-9c19-48eb-9242-18ea48240ba0) ---- This brings the current preview version of CmdPal into the upstream PowerToys repo. There are still lots of bugs to work out, but it's reached the state we're ready to start sharing it with the world. From here, we can further collaborate with the community on the features that are important, and ensuring that we've got a most robust API to enable developers to build whatever extensions they want. Most of the built-in PT Run modules have already been ported to CmdPal's extension API. Those include: * Installed apps * Shell commands * File search (powered by the indexer) * Windows Registry search * Web search * Windows Terminal Profiles * Windows Services * Windows settings There are a couple new extensions built-in * You can now search for packages on `winget` and install them right from the palette. This also powers searching for extensions for the palette * The calculator has an entirely new implementation. This is currently less feature complete than the original PT Run one - we're looking forward to updating it to be more complete for future ingestion in Windows * "Bookmarks" allow you to save shortcuts to files, folders, and webpages as top-level commands in the palette. We've got a bunch of other samples too, in this repo and elsewhere ### PowerToys specific notes CmdPal will eventually graduate out of PowerToys to live as its own application, which is why it's implemented just a little differently than most other modules. Enabling CmdPal will install its `msix` package. The CI was minorly changed to support CmdPal version numbers independent of PowerToys itself. It doesn't make sense for us to start CmdPal at v0.90, and in the future, we want to be able to rev CmdPal independently of PT itself. Closes #3200, closes #3600, closes #7770, closes #34273, closes #36471, closes #20976, closes #14495 ----- TODOs et al **Blocking:** - [ ] Images and descriptions in Settings and OOBE need to be properly defined, as mentioned before - [ ] Niels is on it - [x] Doesn't start properly from PowerToys unless the fix PR is merged. - https://github.com/zadjii-msft/PowerToys/pull/556 merged - [x] I seem to lose focus a lot when I press on some limits, like between the search bar and the results. - This is https://github.com/zadjii-msft/PowerToys/issues/427 - [x] Turned off an extension like Calculator and it was still working. - Need to get rid of that toggle, it doesn't do anything currently - [x] `ListViewModel.<FetchItems>` crash - Pretty confident that was fixed in https://github.com/zadjii-msft/PowerToys/pull/553 **Not blocking / improvements:** - Show the shortcut through settings, as mentioned before, or create a button that would open CmdPalette settings. - When PowerToys starts, CmdPalette is always shown if enabled. That's weird when just starting PowerToys/ logging in to the computer with PowerToys auto-start activated. I think this should at least be a setting. - Needing to double press a result for it to do the default action seems quirky. If one is already selected, I think just pressing should be enough for it to do the action. - This is currently a setting, though we're thinking of changing the setting even more: https://github.com/zadjii-msft/PowerToys/issues/392 - There's no URI extension. Was surprised when typing a URL that it only proposed a web search. - [x] There's no System commands extension. Was expecting to be able to quickly restart the computer by typing restart but it wasn't there. - This is in PR https://github.com/zadjii-msft/PowerToys/pull/452 --------- Co-authored-by: joadoumie <98557455+joadoumie@users.noreply.github.com> Co-authored-by: Jordi Adoumie <jordiadoumie@microsoft.com> Co-authored-by: Mike Griese <zadjii@gmail.com> Co-authored-by: Niels Laute <niels.laute@live.nl> Co-authored-by: Michael Hawker <24302614+michael-hawker@users.noreply.github.com> Co-authored-by: Stefan Markovic <57057282+stefansjfw@users.noreply.github.com> Co-authored-by: Seraphima <zykovas91@gmail.com> Co-authored-by: Jaime Bernardo <jaime@janeasystems.com> Co-authored-by: Kristen Schau <47155823+krschau@users.noreply.github.com> Co-authored-by: Eric Johnson <ericjohnson327@gmail.com> Co-authored-by: Ethan Fang <ethanfang@microsoft.com> Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Clint Rutkas <clint@rutkas.com>
2025-03-19 03:39:57 -05:00
if (!package::IsPackageRegisteredWithPowerToysVersion(PowerRenameConstants::ModulePackageDisplayName))
{
package::RegisterSparsePackage(path, packageUri);
}
}
fix: Context menu registry entries are not cleaned up when disabled via GPO (#41411) <!-- 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 context menu runtime registration wasn't properly cleaned up when GPO (Group Policy Object) policies disabled the module. The problem occurred because the module constructor didn't consider GPO policies when determining its initial enabled state. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #41387 - [ ] **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 This pull request refactors how context menu registration and unregistration are handled across several PowerToys modules. The main improvement is the introduction of a new `UpdateRegistration` helper method in each module, which centralizes and simplifies the logic for registering or unregistering context menus when the module is enabled or disabled. This reduces code duplication and ensures consistent behavior. **Context menu registration logic refactor:** * Added a private `UpdateRegistration` method to each of the following modules to handle context menu registration and unregistration based on the enabled state: - `FileLocksmithModule` in `PowerToysModule.cpp` - `NewModule` in `powertoys_module.cpp` - `ImageResizerModule` in `dllmain.cpp` - `PowerRenameModule` in `dllmain.cpp` * Replaced direct calls to registration/unregistration functions in `enable`, `disable`, and `init_settings` methods with calls to the new `UpdateRegistration` method in all affected modules, ensuring consistent and centralized handling [[1]](diffhunk://#diff-256ed936dafec1bf6ff17849b4797dd276f5b07bebe2e483bc1580c8f06e92d9L91-R122) [[2]](diffhunk://#diff-256ed936dafec1bf6ff17849b4797dd276f5b07bebe2e483bc1580c8f06e92d9R155) [[3]](diffhunk://#diff-4a3942d548f3daec02a833983ed9b2b69f75e2cd1b74a8ce1b874f3fd33fde55L101-R125) [[4]](diffhunk://#diff-4a3942d548f3daec02a833983ed9b2b69f75e2cd1b74a8ce1b874f3fd33fde55L153-R177) [[5]](diffhunk://#diff-0c0a89e812ff4625d165417da14f1c3f203e5ac7907555ae4fde122f3dddcf7aL115-L130) [[6]](diffhunk://#diff-34581ec47c37b0d2e1d9b59696225c47342930694e732db06cbdf653ceb2c2d7L205-R234) [[7]](diffhunk://#diff-34581ec47c37b0d2e1d9b59696225c47342930694e732db06cbdf653ceb2c2d7R334). These changes improve maintainability and reduce the risk of inconsistent registration behavior across modules. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-08-27 19:16:55 +08:00
UpdateRegistration(m_enabled);
}
// Disable the powertoy
virtual void disable()
{
m_enabled = false;
Logger::info(L"PowerRename disabled");
fix: Context menu registry entries are not cleaned up when disabled via GPO (#41411) <!-- 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 context menu runtime registration wasn't properly cleaned up when GPO (Group Policy Object) policies disabled the module. The problem occurred because the module constructor didn't consider GPO policies when determining its initial enabled state. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #41387 - [ ] **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 This pull request refactors how context menu registration and unregistration are handled across several PowerToys modules. The main improvement is the introduction of a new `UpdateRegistration` helper method in each module, which centralizes and simplifies the logic for registering or unregistering context menus when the module is enabled or disabled. This reduces code duplication and ensures consistent behavior. **Context menu registration logic refactor:** * Added a private `UpdateRegistration` method to each of the following modules to handle context menu registration and unregistration based on the enabled state: - `FileLocksmithModule` in `PowerToysModule.cpp` - `NewModule` in `powertoys_module.cpp` - `ImageResizerModule` in `dllmain.cpp` - `PowerRenameModule` in `dllmain.cpp` * Replaced direct calls to registration/unregistration functions in `enable`, `disable`, and `init_settings` methods with calls to the new `UpdateRegistration` method in all affected modules, ensuring consistent and centralized handling [[1]](diffhunk://#diff-256ed936dafec1bf6ff17849b4797dd276f5b07bebe2e483bc1580c8f06e92d9L91-R122) [[2]](diffhunk://#diff-256ed936dafec1bf6ff17849b4797dd276f5b07bebe2e483bc1580c8f06e92d9R155) [[3]](diffhunk://#diff-4a3942d548f3daec02a833983ed9b2b69f75e2cd1b74a8ce1b874f3fd33fde55L101-R125) [[4]](diffhunk://#diff-4a3942d548f3daec02a833983ed9b2b69f75e2cd1b74a8ce1b874f3fd33fde55L153-R177) [[5]](diffhunk://#diff-0c0a89e812ff4625d165417da14f1c3f203e5ac7907555ae4fde122f3dddcf7aL115-L130) [[6]](diffhunk://#diff-34581ec47c37b0d2e1d9b59696225c47342930694e732db06cbdf653ceb2c2d7L205-R234) [[7]](diffhunk://#diff-34581ec47c37b0d2e1d9b59696225c47342930694e732db06cbdf653ceb2c2d7R334). These changes improve maintainability and reduce the risk of inconsistent registration behavior across modules. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-08-27 19:16:55 +08:00
UpdateRegistration(m_enabled);
}
// Returns if the powertoy is enabled
virtual bool is_enabled() override
{
return m_enabled;
}
// Return JSON with the configuration options.
// These are the settings shown on the settings page along with their current values.
virtual bool get_config(_Out_ PWSTR buffer, _Out_ int* buffer_size) override
{
HINSTANCE hinstance = reinterpret_cast<HINSTANCE>(&__ImageBase);
// Create a Settings object.
PowerToysSettings::Settings settings(hinstance, get_name());
2020-01-14 15:17:08 -08:00
settings.set_description(GET_RESOURCE_STRING(IDS_SETTINGS_DESCRIPTION));
settings.set_icon_key(L"pt-power-rename");
// Link to the GitHub PowerRename sub-page
2020-01-14 15:17:08 -08:00
settings.set_overview_link(GET_RESOURCE_STRING(IDS_OVERVIEW_LINK));
2020-05-26 14:12:20 -04:00
settings.add_bool_toggle(
L"bool_persist_input",
2020-01-14 15:17:08 -08:00
GET_RESOURCE_STRING(IDS_RESTORE_SEARCH),
CSettingsInstance().GetPersistState());
2020-05-26 14:12:20 -04:00
settings.add_bool_toggle(
L"bool_mru_enabled",
2020-01-14 15:17:08 -08:00
GET_RESOURCE_STRING(IDS_ENABLE_AUTO),
CSettingsInstance().GetMRUEnabled());
settings.add_int_spinner(
L"int_max_mru_size",
2020-01-14 15:17:08 -08:00
GET_RESOURCE_STRING(IDS_MAX_ITEMS),
CSettingsInstance().GetMaxMRUSize(),
0,
20,
2019-12-20 16:59:20 +03:00
1);
2020-05-26 14:12:20 -04:00
settings.add_bool_toggle(
L"bool_show_icon_on_menu",
2020-01-14 15:17:08 -08:00
GET_RESOURCE_STRING(IDS_ICON_CONTEXT_MENU),
CSettingsInstance().GetShowIconOnMenu());
2020-05-26 14:12:20 -04:00
settings.add_bool_toggle(
L"bool_show_extended_menu",
2020-01-14 15:17:08 -08:00
GET_RESOURCE_STRING(IDS_EXTENDED_MENU_INFO),
CSettingsInstance().GetExtendedContextMenuOnly());
PowerRename: Add Lookbehind (#7571) * Add boost-regex library * If enabled use boost lib for regex Add property `_useBoostLib` to `CPowerRenameRegEx`. If enabled for replacements with regular expressions the Boost Library is used instead of the Standard Library. * Extend signatures to create RegEx with Boost Extend create and constructor singatures of `CPowerRenameRegEx` with an option to enable (or disabled, which is default) the Boost Library. * Verify Lookbehind fails with STD library To verify that the boost library is disabled as expected, check if a lookbehind fails. * Add Unit tests for RegEx with Boost Add unit tests to verify regex replacement with Boost Library. They are copied and adapted from the Standard Library tests. * Improve verify capturing groups test with Boost It is possible to use a capturing group followed by numbers as replacement if the group number is enclosed in curly braces. Added test cases based on the Standard Library tests. * Add useBoostLib to settings interface * Get library option from settings object * Reduce signatures of RegEx by "useBoost" Remove the parameter added in 19105cf, as it became obsolete. * Settings: Read useBoostLib from JSON file * Add UseBoostLib Option to UI * Boost Lib label states the regex syntax difference * Fix Regex with Boost Lib tests - Do not load settings another time in CPowerRenameRegEx ctor - Set flag correctly in standard library regex tests * Add "lookbehind" to dictionary * change Library to lowercase, and also add a comment As suggested by @enricogior. Co-authored-by: Enrico Giordani <enricogior@users.noreply.github.com> * Change Library to lowercase and add a comment As suggested by @enricogior. Co-authored-by: Enrico Giordani <enricogior@users.noreply.github.com>
2020-11-09 19:13:43 +01:00
settings.add_bool_toggle(
L"bool_use_boost_lib",
GET_RESOURCE_STRING(IDS_USE_BOOST_LIB),
CSettingsInstance().GetUseBoostLib());
return settings.serialize_to_buffer(buffer, buffer_size);
}
// Passes JSON with the configuration settings for the powertoy.
// This is called when the user hits Save on the settings page.
virtual void set_config(PCWSTR config) override
{
2019-12-20 16:59:20 +03:00
try
{
// Parse the input JSON string.
PowerToysSettings::PowerToyValues values =
PowerToysSettings::PowerToyValues::from_json_string(config, get_key());
CSettingsInstance().SetPersistState(values.get_bool_value(L"bool_persist_input").value());
CSettingsInstance().SetMRUEnabled(values.get_bool_value(L"bool_mru_enabled").value());
CSettingsInstance().SetMaxMRUSize(values.get_int_value(L"int_max_mru_size").value());
CSettingsInstance().SetShowIconOnMenu(values.get_bool_value(L"bool_show_icon_on_menu").value());
CSettingsInstance().SetExtendedContextMenuOnly(values.get_bool_value(L"bool_show_extended_menu").value());
PowerRename: Add Lookbehind (#7571) * Add boost-regex library * If enabled use boost lib for regex Add property `_useBoostLib` to `CPowerRenameRegEx`. If enabled for replacements with regular expressions the Boost Library is used instead of the Standard Library. * Extend signatures to create RegEx with Boost Extend create and constructor singatures of `CPowerRenameRegEx` with an option to enable (or disabled, which is default) the Boost Library. * Verify Lookbehind fails with STD library To verify that the boost library is disabled as expected, check if a lookbehind fails. * Add Unit tests for RegEx with Boost Add unit tests to verify regex replacement with Boost Library. They are copied and adapted from the Standard Library tests. * Improve verify capturing groups test with Boost It is possible to use a capturing group followed by numbers as replacement if the group number is enclosed in curly braces. Added test cases based on the Standard Library tests. * Add useBoostLib to settings interface * Get library option from settings object * Reduce signatures of RegEx by "useBoost" Remove the parameter added in 19105cf, as it became obsolete. * Settings: Read useBoostLib from JSON file * Add UseBoostLib Option to UI * Boost Lib label states the regex syntax difference * Fix Regex with Boost Lib tests - Do not load settings another time in CPowerRenameRegEx ctor - Set flag correctly in standard library regex tests * Add "lookbehind" to dictionary * change Library to lowercase, and also add a comment As suggested by @enricogior. Co-authored-by: Enrico Giordani <enricogior@users.noreply.github.com> * Change Library to lowercase and add a comment As suggested by @enricogior. Co-authored-by: Enrico Giordani <enricogior@users.noreply.github.com>
2020-11-09 19:13:43 +01:00
CSettingsInstance().SetUseBoostLib(values.get_bool_value(L"bool_use_boost_lib").value());
CSettingsInstance().Save();
Trace::SettingsChanged();
}
catch (std::exception& e)
2019-12-20 16:59:20 +03:00
{
Logger::error("Configuration parsing failed: {}", std::string{ e.what() });
}
}
// Signal from the Settings editor to call a custom action.
// This can be used to spawn more complex editors.
virtual void call_custom_action(const wchar_t* /*action*/) override
{
}
// Destroy the powertoy and free memory
virtual void destroy() override
{
delete this;
}
void init_settings()
{
m_enabled = CSettingsInstance().GetEnabled();
fix: Context menu registry entries are not cleaned up when disabled via GPO (#41411) <!-- 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 context menu runtime registration wasn't properly cleaned up when GPO (Group Policy Object) policies disabled the module. The problem occurred because the module constructor didn't consider GPO policies when determining its initial enabled state. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #41387 - [ ] **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 This pull request refactors how context menu registration and unregistration are handled across several PowerToys modules. The main improvement is the introduction of a new `UpdateRegistration` helper method in each module, which centralizes and simplifies the logic for registering or unregistering context menus when the module is enabled or disabled. This reduces code duplication and ensures consistent behavior. **Context menu registration logic refactor:** * Added a private `UpdateRegistration` method to each of the following modules to handle context menu registration and unregistration based on the enabled state: - `FileLocksmithModule` in `PowerToysModule.cpp` - `NewModule` in `powertoys_module.cpp` - `ImageResizerModule` in `dllmain.cpp` - `PowerRenameModule` in `dllmain.cpp` * Replaced direct calls to registration/unregistration functions in `enable`, `disable`, and `init_settings` methods with calls to the new `UpdateRegistration` method in all affected modules, ensuring consistent and centralized handling [[1]](diffhunk://#diff-256ed936dafec1bf6ff17849b4797dd276f5b07bebe2e483bc1580c8f06e92d9L91-R122) [[2]](diffhunk://#diff-256ed936dafec1bf6ff17849b4797dd276f5b07bebe2e483bc1580c8f06e92d9R155) [[3]](diffhunk://#diff-4a3942d548f3daec02a833983ed9b2b69f75e2cd1b74a8ce1b874f3fd33fde55L101-R125) [[4]](diffhunk://#diff-4a3942d548f3daec02a833983ed9b2b69f75e2cd1b74a8ce1b874f3fd33fde55L153-R177) [[5]](diffhunk://#diff-0c0a89e812ff4625d165417da14f1c3f203e5ac7907555ae4fde122f3dddcf7aL115-L130) [[6]](diffhunk://#diff-34581ec47c37b0d2e1d9b59696225c47342930694e732db06cbdf653ceb2c2d7L205-R234) [[7]](diffhunk://#diff-34581ec47c37b0d2e1d9b59696225c47342930694e732db06cbdf653ceb2c2d7R334). These changes improve maintainability and reduce the risk of inconsistent registration behavior across modules. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-08-27 19:16:55 +08:00
UpdateRegistration(m_enabled);
Trace::EnablePowerRename(m_enabled);
}
void save_settings()
{
Trace::EnablePowerRename(m_enabled);
}
PowerRenameModule()
{
init_settings();
app_name = GET_RESOURCE_STRING(IDS_POWERRENAME_APP_NAME);
app_key = PowerRenameConstants::ModuleKey;
LoggerHelpers::init_logger(app_key, L"ModuleInterface", LogSettings::powerRenameLoggerName);
}
2020-01-14 15:00:05 -08:00
~PowerRenameModule(){};
};
extern "C" __declspec(dllexport) PowertoyModuleIface* __cdecl powertoy_create()
{
return new PowerRenameModule();
2020-01-17 11:12:23 -08:00
}