Skip to content

Auto Theme Switcher v.1.3.2#4515

Open
tinodin wants to merge 2 commits into
ramensoftware:mainfrom
tinodin:auto-theme-switcher-v.1.3.2
Open

Auto Theme Switcher v.1.3.2#4515
tinodin wants to merge 2 commits into
ramensoftware:mainfrom
tinodin:auto-theme-switcher-v.1.3.2

Conversation

@tinodin

@tinodin tinodin commented Jun 21, 2026

Copy link
Copy Markdown
Contributor

Changelog

If this pull request updates an existing mod, describe the changes below:

  • Fix applying lockscreen wallpaper by injecting into explorer.exe again and clearing lock screen cache

Mod authorship

If this pull request introduces a new mod, please complete the section below.

This mod was created by:

    • The submitter, without AI assistance
    • The submitter, with AI assistance
    • Claude
    • ChatGPT
    • Gemini
    • Another AI (please specify):
    • Other (please specify):

Please select the options that best apply. Your selection does not affect the acceptance criteria, but it helps reviewers understand the context of the code and provide relevant feedback.

tinodin added 2 commits June 21, 2026 17:49
- Fix applying lockscreen wallpaper by injecting into explorer.exe again and clearing lock screen cache
@m417z

m417z commented Jun 22, 2026

Copy link
Copy Markdown
Member

Submission review

Note: This review was done by Claude, and then refined manually. Due to the amount of submissions, doing a fully manual review for each pull request is no longer feasible. Thank you for understanding.

Please address the following issues. The items in the collapsed sections are optional, so it's your call whether to address them.

For the first item, I'm not sure about the over-deletion, but the path concern makes sense.


  • ClearLockScreenCache deletes lock-screen cache values it doesn't own, and over-broadly. The new function reaches into HKCU\…\Lock Screen and, the moment any one of Details_ADetails_G matches the hardcoded string IMAGENAME:C:\Program Files\Windhawk\windhawk.exe, it deletes all seven slots' Details_/ImageId_/OriginalFile_ values. Two problems:

    • Over-deletion. If the user has Spotlight or any manually-set lock-screen image cached in the other slots, those get wiped too, forcing Windows to rebuild the cache. The deletion should be scoped to only the slots that actually reference the mod's own stale entry.
    • Hardcoded install path. Windhawk can be installed outside C:\Program Files\Windhawk (custom/portable installs). For those users the exact-match fails, so the stale-entry cleanup this PR is meant to perform silently never runs — defeating the fix for exactly the users migrating from the v1.3.1 windhawk.exe host. Match on the windhawk.exe file name instead of the full path.

A version that fixes both — match by file name, delete only matching slots:

auto isWindhawkEntry = [](PCWSTR s) -> bool {
    constexpr PCWSTR kPrefix = L"IMAGENAME:";
    if (_wcsnicmp(s, kPrefix, 10) != 0) return false;
    PCWSTR path = s + 10;
    PCWSTR name = wcsrchr(path, L'\\');
    return _wcsicmp(name ? name + 1 : path, L"windhawk.exe") == 0;
};

for (wchar_t c = L'A'; c <= L'G'; ++c) {
    std::wstring suffix(1, c);
    wchar_t data[512];
    DWORD dataSize = sizeof(data);
    if (RegGetValueW(hKey, NULL, (L"Details_" + suffix).c_str(), RRF_RT_REG_SZ, NULL, data, &dataSize) == ERROR_SUCCESS
        && isWindhawkEntry(data)) {
        RegDeleteValueW(hKey, (L"Details_" + suffix).c_str());
        RegDeleteValueW(hKey, (L"ImageId_" + suffix).c_str());
        RegDeleteValueW(hKey, (L"OriginalFile_" + suffix).c_str());
        Wh_Log(L"Cleared Lock Screen cache slot %c", c);
    }
}

If the slots are genuinely interdependent and Windows needs all of them cleared together for the rebuild to take effect, that's fine — but then say so in a comment, because as written it reads like an unintentional "match one, nuke all." You've tested the behavior, so you're best placed to judge; the install-path-agnostic match is the part that's clearly worth keeping regardless.

This is also a persistent registry deletion that isn't undone when the mod is disabled. It's defensible as a one-time migration cleanup of the mod's own footprint (the entries it created), which is why it's not a blocker — but keeping it scoped to only the mod's entries is what keeps it within Windhawk's "no persistent system changes" principle.

  • Add a comment explaining why explorer.exe is targeted. The hollow-explorer.exe host does preserve the crash-isolation benefit of a tool mod (a scheduler crash kills only the phantom process, not the shell), which is a point in favor of this approach over running the scheduler directly inside the real shell explorer.exe. If the explorer identity really is required for the lock-screen API, this is a reasonable way to keep both that identity and crash isolation — worth a short code comment noting the intent, since the tool-mod boilerplate comment still says "dedicated windhawk.exe process," which no longer matches reality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants