Fix #3736

[younesaassila]

Type of Change

• New feature
• Bug fix
• Documentation update
• Refactoring
• Hotfix
• Security patch
• UI/UX improvement

Description

Starting in version 25.11.17, Customize Preferences toggles stopped working (see #3736). The issue has started from commit 25c5247 (introduced in PR #3625).

I've realized from testing that before this change, when the condition was still $Checkbox -contains "Toggle", that the corresponding if was never called because $Checkbox is always a string (whether tweak or toggle), thus -contains always returned $false.

Changing from -contains to -like thus made the if statement's code execute for toggles. If you look at what it is doing, it sets $CheckBox to $sync.configs.tweaks.$CheckBox (object), but then later on the code continues to use $CheckBox in lines like $sync.configs.tweaks.$CheckBox as if it were a string, thus making the code fail for toggles since they are now objects.

I thus looked for the source of this if statement appearance in 1d0e3bf (PR #3014). When looking at the Invoke-WinUtilTweaks.ps1 file, this if statement is added (in a broken form like I said before since -contains is always $false in this context), while $sync.configs.tweaks.$CheckBox code lines already exist and are left untouched.

In conclusion, it is likely this if block has been there by error doing nothing up until now, where it's behavior has been enabled by 25c5247, resulting in broken functionality. This PR removes this if statement, since no other parts of the code use this sort of logic (from what I've found, the code always uses the $sync.configs.tweaks.* pattern expecting a string).

Testing

Tested -contains, -like, and no if block configurations in Windows Sandbox. -contains worked fine, -like broke toggles, no if statement worked fine.

Impact

No impact

Issue related to PR

• Resolves Customize Preference not working #3736
• Resolves Toggle not working #3746

Additional Information

The #3625 PR adding this change claims their commit fixed an issue where selecting the "Set Classic Right-Click Menu" tweak would result in the script applying registry changes for the "Cross-Device Resume" tweak instead.

I have not been able to reproduce this issue in any of the tested configurations. Either this bug has been fixed by another PR, or it is not linked to this if block.

Checklist

• My code adheres to the coding and style guidelines of the project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no errors/warnings/merge conflicts.

[GabiNun]

good job

[QbikEdge]

Yea it make sense. The only place $CheckBox change would be used is here:

Write-Debug "Tweaks: $($CheckBox)"

and i would argue it makes debug not easier if you change
WPFToggleDarkMode with System.Collections.Hashtable+SyncHashtable.configs.tweaks.WPFToggleDarkMode

Or am i wrong?

because for dark mode toggle is..

• the value of $CheckBox -> WPFToggleDarkMode
• the value of $sync.configs.tweaks.$CheckBox -> System.Collections.Hashtable+SyncHashtable.configs.tweaks.WPFToggleDarkMode

[younesaassila]

Yea it make sense. The only place $CheckBox change would be used is here:

Write-Debug "Tweaks: $($CheckBox)"

and i would argue it makes debug not easier if you change

WPFToggleDarkMode with System.Collections.Hashtable+SyncHashtable.configs.tweaks.WPFToggleDarkMode

Or am i wrong?

because for dark mode toggle is..

• the value of $CheckBox -> WPFToggleDarkMode

• the value of $sync.configs.tweaks.$CheckBox -> System.Collections.Hashtable+SyncHashtable.configs.tweaks.WPFToggleDarkMode

Yes it makes the debug log more complicated for no good reason