Windows 11 Start menu still opens in the center, could it respect Windows setting?

[Gaurav-Original-ClassicShellTester]

Although personally I use third party Start menus with the Classic Taskbar, with ExplorerPatcher 22000.168.0.10, the Windows 11 Start menu or its search still opens in the center even if before or after switching to the classic Taskbar, the alignment is set to Left from Settings.

[valinet]

Yeah, I know, it is the latest thing on my mind, I wanted to work on it but the other stuff I thought was more important on the priorities list. It bothers me a bit because I personally don't use a Start menu replacement as the way I use Start is anyway just for searching or hitting the few shortcuts I pin there, and getting to the menu after clicking the Start button is a bit hard on the big monitors I have at my desk.

I wonder where the behavior of ignoring the "Left/Center" setting is coming from. The way I imagine it, as the setting is actually called "Taskbar alignment", that just sets where the taskbar will align its icons, and then the menu just looks for the Start button I think and kind of adjusts to that. Or something like that, I don't think the Start menu reads this setting directly, I think it looks for something in the new taskbar to determine where to position itself, and since the new taskbar is not running, it just defaults to center.

Also, I wonder if it is tied to search. Like, if I manage to make Start open on the left, will search follow it naturally there? Also, I wonder whether it is possible to achieve this from Explorer, because the menu is hosted by StartMenuExperienceHost.exe but the way it seems to me, clearly communicates with Explorer somehow and gets some data from it, because otherwise it would just respect the registry setting.

I will investigate this, hopefully I also find something meaningful along the way. First thing is to determine when TaskbarAl is queried and by who, and go from there, I guess (ProcessMonitor to the rescue).

[Gaurav-Original-ClassicShellTester]

The funny thing is I was playing around with Winaero Tweaker and I set Taskbar to the top. Then the floating Windows 11 menu opens on the top left (but slides in from the bottom) 😂 But if I type something, the search opens in the middle.

[valinet]

@Gaurav-Original-ClassicShellTester Yeah, for me, when I set taskbar to top, Start menu will open on the top left, while search indeed gets on top but it remains centered. There is no registry access for StuckRects3, so it seems that the Start menu and Explorer communicate somehow in some other way...

[valinet]

So yeah, after much trial and error, I managed to pull it off: now the Start menu and search appear to the left, I added support for that in the latest release (22000.168.0.14). I am glad we made it to this point, I can now take it slowly and polish things here and there and hopefully refactor some of the code a bit, I feel like it deserves that. I also updated the README with information about these latest changes, and I hope that this version works well, I consider it fairly mature and worth using on a daily basis.

And I was proven wrong, the Start menu actually gets the taskbar alignment directly at startup and then it is notified of changes by some mechanism related to the SystemSettings_DesktopTaskbar "class" I believe.

But initially, when it starts, it uses some API to read it directly into a member of the class (struct), specifically it uses WindowsUdk::UI::Shell::ITaskbarLayout::GetAlignment. That call returns some pointer from which you use a helper to get the actual value: 0 for left aligned, 1 for centered. But the API does not work when using the classic taskbar, so the assignment to the class member variable is skipped. It is set to a default value though, and that is, you guessed it: 1, so centered. That's why with the classic taskbar, Start is always centered, as that is the default value they initialize that member to (it's funny that they actually make it 0 initially and then hard code set it to 1 a few instructions below). So, yeah, naturally, I just set it myself afterwards by hooking that function.

Oh, I so much wish the Windows GUI stuff would get open sourced...

[Gaurav-Original-ClassicShellTester]

Ohh! Love your analysis and explanation on how things work.

This works fantastic!

This version seems to interfere with StartIsBack++ again.

[valinet]

Yeah, good point. I will add this mention to the README at some point.

Also, idk, maybe using the pregenerated files should be preffered first for new users, and then the automatic symbol download? Idk, I will think about it…

I wonder why StartIsBack interferes with its patching though. I mean, probably it restarts Explorer as well and multiple instances spawn and the offset to patch cannot b determined correctly because a race condition naturally appears… just a guess. Yeah, advice is, during the initial analysis, temporarily disable any stuff that gets in Explorer, afterwards it should work just fine, indeed.

[Gaurav-Original-ClassicShellTester]

For now until you figure out the race condition, I have put the 22000.168.0.12 version of the DLL in C:\Windows and 22000.168.0.14 in Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy and MicrosoftWindows.Client.CBS_cw5n1h2txyewy.

Otherwise it was causing slow logon again with StartIsBack++ installed. But worse, with Open Shell also installed, Shift+Win key wasn't opening the Windows 11 Start menu until I exited Open Shell's menu, press Win key once and again started Open Shell's menu in which case it would begin functioning normally.

But with the above setup, everything works. No slow logon, no compatibility issues with any Start menus with 22000.168.0.12 in C:\Windows and the 22000.168.0.14 DLL makes sure it appears on the left.

[valinet]

Can you retest 22000.168.0.14 in C:\Windows, please? I have uploaded a new version in-place in Releases that restores the original fix for logon delay. Download that and try again please. Can you check if it works like 22000.168.0.12? Thanks.

[Gaurav-Original-ClassicShellTester]

FIXED! :D Now no issues with the latest DLL in C:\Windows and in other locations too. Updated everywhere.

Slow logon is fixed. Open Shell Win key compatibility issues also gone.

So far so good. If I discover any issues, I will of course let you know.

[valinet]

Yeah, the interference with OpenShell and Win key is related to the fact that I also hook the ProgMan window and intercept the SC_TASKLIST message which means Start is about to be opened. I do that since I also implement that feature which OpenShell already has where it opens the Start menu on the monitor with the mouse. But since I am not aware of OpenShell in my code, I always display the Start menu. If my hook runs before OpenShell's, that's what probably breaks it. But I only when the following registry key is set to 0: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage\MonitorOverride. Do you have that set to 0? If you delete it, then the problem should not happen anymore. Can you check, please?

[valinet]

Also, the delay at logon is tricky. The correct way I think is to wait for the Start button to be created, wait a bit more (300ms) and then dismiss the logon screen. That's what I had in 22000.168.0.14. But you said it causes problems. The behavior in 22000.168.0.12 which I have restored is to wait 2 seconds... I don't know, maybe wait for Start to be created and then wait some more (like 1s)... for me, it works, that's the thing... Or have it as a setting...? Maybe that would be the best idea.

[valinet]

Yeah, so redownload the DLL from Releases, add ExplorerReadyDelay=2000 in the [General] section in settings.ini and that should restore the behavior in 22000.168.0.12 pretty much, which is to wait 2 seconds at logon and then signal shell ready. Default is to look for the Start button, wait 600ms, and then signal shell ready. Idk, makes sense to me like this at the moment...

[Gaurav-Original-ClassicShellTester]

MonitorOverride is not present at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage. However I did experiment with it, setting it to 1. But it didn't work for me to open the Windows 11 menu with the Win key on the active monitor. So I deleted the value. I use Open Shell's Setting anyway which I had requested Ivo to add :D, "Open Windows Start menu on monitor with the mouse" since it works reliably for all menus - the Open Shell menu, and the Windows 10/11 menus.

[Gaurav-Original-ClassicShellTester]

OK I figured MonitorOverride=0 makes it work. Yes that's working. But it overrides Open Shell's Win key to open its menu completely to I will keep it at 1 or deleted :)

[valinet]

MonitorOverride is enabled when set to 0 and disabled when set to 1. Having it deleted is equivalent to it being 1, that's what the behavior was in Windows 8 and I stuck to that, even if it does not make much sense in my opinion. Depends on how you look at it.

Anyway, I still don't understand what is the lucky combination finally... so, does ExplorerPatcher interfere anymore, is it deterministic or is it racing with OpenShell at startup, how does it go? As I said, without MonitorOverride, ExplorerPatcher and OpenShell should not interfere at all in anything...

[valinet]

OK I figured MonitorOverride=0 makes it work. Yes that's working. But it overrides Open Shell's Win key to open its menu completely to I will keep it at 1 or deleted :)

Okay, that happens for me as well, it is probably because my hook gets executed first and I always open the Windows 11 Start menu, as I don't know about OpenShell in my code. Makes sense. Yeah, just disable the feature in ExplorerPatcher and use OpenShell's, the code is identical as I took it from in there =)))

[Gaurav-Original-ClassicShellTester]

Right now with the latest DLL you updated, there are no issues. Should I still fiddle with the ExplorerReadyDelay=2000 value?

[valinet]

The DLL right now on GitHub releases is the same as the one from 6 hours ago, only thing is I added an option to manually specify the time after which the Explorer ready signal should be fired, which has the effect of dismissing the login screen. If you say it works with the built-in method, which is look for Start button, wait 600ms and then fire the event, then all good. Idk, see how it goes further on and report back, it is hard to test this kind of stuff on a sample size of 1 computer on which I also develop. If the feedback now is good, I am happy :D