waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Aug 10, 2024 13:58:01 GMT -8
This mod aims to fix various problems with file explorer appearance and behaviour on windows 11 22H2 and above, that are caused by stupid micr  soft modifications to explorerframe.dll There are two problems to be fixed: the menu bar appears spuriously only if one of the three conditions is met (change in screen resolution, change of system theme, passing of a random amount of time), and the SysListView32 lagging on navigation to a new folder if Classic theme is used, which is more visible when the file explorer window is first created, because nothing has been rendered yet in that area of the window, hence the user sees a black rectangle. |
|
|
|
Post by nonameneeded on Aug 10, 2024 16:38:06 GMT -8
The menu bar doesn't cause any problems even on Win11 23H2.
However, the problem of the disappearing menu bar will occur as soon as you install updates (it's not only one but many of them) but the problem is not kind of "baked" into 23H2, that's what I'm trying to say.
And the only solution for the other problems seems to be the usage of an older explorerframe.dll file (and its corresponding mui file).
I use the one from 22H2 and it seems to work fine.
But of course the (laggy) Explorer tabs are gone.
|
|
|
|
Post by anixx on Aug 10, 2024 18:28:34 GMT -8
Simply great!
If this mod forces menubar always on, then I suggest to separate these two fixes into different mods, because some people do not use menubar but may suffer from black rectangles.
Also, there are reports by users that the menubar randomly appears in 23h2 when it is not needed. Maybe the mod could fix this issue as well?
|
|
|
|
Post by anixx on Aug 10, 2024 19:55:35 GMT -8
Your fix does not work well for me:
No menu items appear on the menubar.
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Aug 11, 2024 5:16:56 GMT -8
I changed the internal workings of the mod. Perhaps now it will work for you. I've also adden a option to show/hide the menubar as per your suggestion. It works by overriding the LPARAM in the WndProc, with the value from the mod settings. Now, on to the harder issue, which is the delay. I've done some more experimentation and I think the problem is purely visual - and it isn't that the SysListView32 isn't drawn at all, either. If you take a screen in just the right moment, you can see that the CLIENTEDGE is drawn around the black box. And, the SysListView32 responds to user actions just as usual during the delay, you can see that if you have nested folders and double click on them fast enough, so that the second navigation event takes place before the delay elapses. This way, you will not see the contents of the middle folder (like you would before 23H2), you will only see the final folder. This means that the window isn't hanging like I thought it may be.
Also, what is your 11 version? I'm testing on 23H2. Maybe the problem is somehow different on 24H2.
|
|
|
|
Post by anixx on Aug 11, 2024 6:09:28 GMT -8
I changed the internal workings of the mod. Perhaps now it will work for you. I've also adden a option to show/hide the menubar as per your suggestion. It works by overriding the LPARAM in the WndProc, with the value from the mod settings. Now, on to the harder issue, which is the delay. I've done some more experimentation and I think the problem is purely visual - and it isn't that the SysListView32 isn't drawn at all, either. If you take a screen in just the right moment, you can see that the CLIENTEDGE is drawn around the black box. And, the SysListView32 responds to user actions just as usual during the delay, you can see that if you have nested folders and double click on them fast enough, so that the second navigation event takes place before the delay elapses. This way, you will not see the contents of the middle folder (like you would before 23H2), you will only see the final folder. This means that the window isn't hanging like I thought it may be.
Also, what is your 11 version? I'm testing on 23H2. Maybe the problem is somehow different on 24H2.
My Windows version is 23h2. I think, the black box issue affects not only SysListView32 but also the default control, albeit a bit less (it is visible if you are opening "God mode" control panel or the Network Connections folder). But it appears only under Classic theme.
P.S. Just tested, still the menubar remains empty.
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Aug 11, 2024 7:06:48 GMT -8
I found the reason. It was related to the Throbber from ClassicExplorer. If the Throbber is absent, then the menu bar items would be invisible, for some retarded reason. Fortunately I'm familiar with how ClassicExplorer does things so I knew that it has a function to fix the layout of ShellTabWindowClass. I copied that fix, a few lines of code, into my mod and now the menu bar is visible. As a side effect, if any band object (such as the Throbber or the address bar) is being enabled, the layout for that file explorer window will become bugged (not badly so, but it's annoying). Opening a new file explorer window fixes that. I'll look into how to get rid of this problem for good some time later.
|
|
|
|
Post by anixx on Aug 11, 2024 7:13:47 GMT -8
I found the reason. It was related to the Throbber from ClassicExplorer. If the Throbber is absent, then the menu bar items would be invisible, for some retarded reason. Fortunately I'm familiar with how ClassicExplorer does things so I knew that it has a function to fix the layout of ShellTabWindowClass. I copied that fix, a few lines of code, into my mod and now the menu bar is visible. As a side effect, if any band object (such as the Throbber or the address bar) is being enabled, the layout for that file explorer window will become bugged (not badly so, but it's annoying). Opening a new file explorer window fixes that. I'll look into how to get rid of this problem for good some time later. Indeed, now appears well. |
|
|
|
Post by anixx on Aug 11, 2024 7:21:04 GMT -8
I found the reason. It was related to the Throbber from ClassicExplorer. If the Throbber is absent, then the menu bar items would be invisible, for some retarded reason. Fortunately I'm familiar with how ClassicExplorer does things so I knew that it has a function to fix the layout of ShellTabWindowClass. I copied that fix, a few lines of code, into my mod and now the menu bar is visible. As a side effect, if any band object (such as the Throbber or the address bar) is being enabled, the layout for that file explorer window will become bugged (not badly so, but it's annoying). Opening a new file explorer window fixes that. I'll look into how to get rid of this problem for good some time later. I found that the black background appears because the ShellTabWindowClass control does not have attribute "Visible" when created. If to make it visible, the area is white.
Or, maybe, CabinetWClass background should be made non-black...
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Aug 11, 2024 10:28:33 GMT -8
Some of my findings so far: Using x64dbg, I set breakpoints on the beginnings of CDefView::_CallRefresh and CDefView::OnPaintDone on both 10 and 11. The behaviour differs significantly at both of those under 10 and 11. On 10, at the first breakpoint the listview background color and the client edge is rendered correctly, but no items. At the second breakpoint all of the contents, items and all, are rendered in full. On 11, at the first breakpoint the client edge is rendered correctly, but the background is black. At the second breakpoint, no change is observed. It isn't until some time after CDefView::OnPaintDone returns that the listview is rendered.
When SysListView32 is disabled in favor of it's "modern" (sorry friend, pal, amigo  ) variant at the first breakpoint the the background color is rendered and a text "We're working on it" on top. Second breakpoint isn't hit, interesingly. The window is just rendered to the screen like that. We know for a fact that replacing the explorerframe.dll with a older version fixes this particular problem. Maybe it's worth it to compare the call stacks after replacing explorerframe.
|
|
|
|
Post by anixx on Aug 11, 2024 10:40:49 GMT -8
If only we could make non-black background, it would be quite a progress.
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Aug 11, 2024 11:48:11 GMT -8
I swapped the explorerframe.dll for the 22000 version, and the only difference is there is no black box on first loading of the window. The delay is all the same, which arguably is the more dire problem of the two. It may well be the case that the underlying issue isn't in explorerframe after all.
|
|
|
|
Post by anixx on Aug 11, 2024 12:45:23 GMT -8
I swapped the explorerframe.dll for the 22000 version, and the only difference is there is no black box on first loading of the window. The delay is all the same, which arguably is the more dire problem of the two. It may well be the case that the underlying issue isn't in explorerframe after all. I do not see any delay in either case. The only issue is the black box.
But other users reported the delay as well.
|
|
|
|
Post by anixx on Aug 12, 2024 2:41:53 GMT -8
I swapped the explorerframe.dll for the 22000 version, and the only difference is there is no black box on first loading of the window. The delay is all the same, which arguably is the more dire problem of the two. It may well be the case that the underlying issue isn't in explorerframe after all. I suggest you to submit these two fixes separately because the menubar issue does not only affect the classic theme. It even affects those who does not want to see the menu: |
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Aug 12, 2024 3:55:38 GMT -8
Ok, will do. But before the menu bar fix mod may be released, I need to fix the problem with file explorer layout being destroyed sometimes.
|
|
|
|
Post by anixx on Aug 12, 2024 8:19:38 GMT -8
Just noticed that "This PC" folder always starts without the black background...
|
|
|
|
Post by anixx on Aug 12, 2024 12:18:21 GMT -8
Ok, will do. But before the menu bar fix mod may be released, I need to fix the problem with file explorer layout being destroyed sometimes. Or maybe may suggestion was not optimal. I think, two injected dlls would take more resources than one... Maybe, one mod named just "Explorer frame fixes for 23H2+" would be better... Just bear in mind it affects not only Classic users... Decide yourself.
|
|
Jevil7452
Regular Member
Posts: 431
OS: Windows Vista Enterprise (6.0.6003)/Windows 7 Enterprise (6.1.7601)
Theme: Windows Aero by Microsoft Corporation (on both)
CPU: Intel Core i7-3770k
RAM: 32GB (4x8GB DDR3)
GPU: NVIDIA GeForce GTX 980 Ti + Intel(R) HD Graphics 4000
Computer Make/Model: OEM0
|
Post by Jevil7452 on Aug 13, 2024 2:41:54 GMT -8
Make it so the user can toggle options as wanted
|
|
|
|
Post by anixx on Aug 13, 2024 3:58:41 GMT -8
Make it so the user can toggle options as wanted If the black box issue is fixed, I do not think, it will negatively affect anybody. |
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Aug 13, 2024 8:08:12 GMT -8
I fixed the delay. It was caused by redrawing being disallowed because WM_SETREDRAW with wParam == false being sent to the listview window procedure. I discovered this by comparing the messages sent to the listview - compared to 10, there is one extra message on 11, which blocked drawing of the listview. My naive solution is to just castrate WM_SETREDRAW by setting wParam to true every time it's processed in the subclass. A better solution is certainly possible, but time will tell if that's really needed.
That being said, the black box is still there, but it's visible for a much shorter period of time now, sometimes not at all. What was your solution to getting rid of the black box? Can you provide the code?
Regarding whether the mod should be divided into two or not, let's consider the pros and cons of dividing it into two. If I elect to release the fixes divided into two mods, they could both get unambiguous names and descriptions. If I relase it as one, I would need to skip "Classic" in the mod name because the menu fix also caters to general Win11 users. Then again, your point of loading two dll files is a valid concern. Also, what should be the name for the combined mod? "Explorerframe fixes" or the like wouldn't do the mod justice, as it does hook shell32 as well to get hold of the listview immediately after it's created, even though the original fault appears to be in explorerframe. "File explorer fixes for 11 22H2" isn't specific enough.
EDIT: For now the fixes will be released in this topic as one mod for beta testing. I'll decide what to do exactly after gathering some more user input.
EDIT2: Confirmed working on 24H2 too.
|
|
soft modifications to explorerframe.dll
