Classic explorerframe fixes for 22H2+

The issues you're experiencing are the side effect of the invisible menu items fix. It shouldn't be too hard to fix.

As for your fix, I meant this:

So you're saying that if ShellTabWindowClass is made visible immediately following it's creation, the background color is COLOR_WINDOW?

During class registering, the hbrBackground color for CabinetWclass is set to COLOR_BTNFACE on both 10 and 11. Some time between class registration and CBandSite::_Initialize which I used to probe the hbrBackground for changes, it is changed to NULL which indicates that the window procedure for CabinetWClass handles clearing the rect. I tried hooking SetWindowLongPtrW to intercept this, but it didn't work. Now I'm trying to find a symbol to hook into the wndproc of CabinetWClass. A ordinary Windhawk subclass will not work because we need to get hold of every single message, including the very first ones. I'd rather avoid hooking CreateWindowExW so as not to provoke conflict with ExplorerPatcher. It's the same problem that made my Treeview mod crash every now and then, or not work at all.

My findings on the black box lead me to believe that this problem isn't exclusive to 11 22H2+ or even 11 really, the same thing can be observed on 10 22H2, but the box is white instead of black. Looks equally as shitty if a dark classic theme is used. This means that the fix for this particular problem would be useful not only for 11 22H2 users, but for all classic theme SysListView32 users. Therefore it would be better if it was part of a SysListView32 enabler mod, or ExplorerPatcher.

Some time later I'll add my two cents to the relevant ExplorerPatcher issue because my findings would help ExplorerPatcher.

Now I'm releasing the functionally done version here, but I'll still try to solve the WM_SETREDRAW issue more elegantly, as my current solution can be likened to a demoltion hammer blow to a head.

I do not think this fix negatively affects anyone. Probably, would be better to have it enabled by default, for instance so that I could recommend it in tutorials on Classic theme without further explanations of how to set it up.

Does it bring any troubles to non-classic users? I think, no. I think, the both (actually, all 3) fixes are purely positive and only small part of users (if any) would want to disable one of them.

Potentially yes, but this family of mods is fundamentally flawed because they hook CreateWindowExW which is incompatible with ExplorerPatcher. I've discovered that if the Navigation bar is disabled in ExplorerPatcher, then the mod you're talking about doesn't work at all.

Overall, I think mods that modify explorer.exe shouldn't hook CreateWindowExW at all - and in most cases they don't have to, there are countless symbols that can be hooked to the same effect. SetWindowLongPtrW may be impacted too.

It seems that the author is doing a good job keeping track of problems and fixing them. I've got two remarks: firstly you've mentioned that the mod fails to fix the ExplorerPatcher taskbar implementation. That's because ExplorerPatcher taskbar is a reimplementation, not a mod. Apparently they are working on various theme related options, so maybe in not-so-distant future we will not need any Windhawk mods or OpenShell patches to have a fully classic taskbar on Win 11 24H2. Second, one of the issues you've posted a screen of, I experienced that too with your Classic Taskbar 3d buttons lite:

Anyways, not too big of a problem, and not really relevant here.

Thanks for the kind words OrthodoxWin32. Sometimes I enjoy solving a problem like this - I'm fighting the good fight against post-modernity