Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Win+Q combination does not work #10

Closed
Gaurav-Original-ClassicShellTester opened this issue Aug 31, 2021 · 6 comments
Closed

Win+Q combination does not work #10

Gaurav-Original-ClassicShellTester opened this issue Aug 31, 2021 · 6 comments
Labels
Bug Something isn't working fixed

Comments

@Gaurav-Original-ClassicShellTester

So I usually run some AutoHotkey scripts on my PC for custom hotkey shortcuts. One of the scripts uses Win key shortcuts that Windows does not use. This is the AHK:

#Persistent
#SingleInstance, Force
#y::Run, mblctr.exe, C:\Windows\system32
#q::Run, ms-availablenetworks:
#j::Run, control.exe /name Microsoft.WindowsUpdate

However when I run this AHK or its compiled EXE version, Win+X also opens ms-availablenetworks: instead of opening the Win+X menu. Definitely some conflict. Is it because of this? #3

@Gaurav-Original-ClassicShellTester

Ok it seems Win+Q opens search as well as Win+S. And Win key also opens search. So I thought Win+Q was redundant, chose to remap it. I switched to Win+O instead for ms-availablenetworks: . Problem solved. Now Win+X opens that menu as expected. Win+O is only used for changing orientation on tablet PC/detachable rotatable tablets so I have no use for it. Can remap it. :)

@valinet
Copy link
Owner

valinet commented Aug 31, 2021

Yes, it is because of that (#3). The way it works right now is the Win+X combination is caught in a hooked CTray::HandleGlobalHotkey (from twinui.pcshell) but because I cannot get a pointer to the CLauncherTipContextMenu instance from there using the COM interface query from there properly, my workaround was to fire a key combination (Win+Q) that is then caught in a hooked CImmersiveHotkeyNotification::OnMessage (from twinui) and from there open the menu, which works. That is definitely hacky and should be corrected, but I don't know why invoking the menu directly from the first callback does not work, it just gets me a different pointer every time.

So, yes, it will be fixed eventually, once I figure out how; I know about it. Like, I have the code already, but for some reason it just does not work properly...

@valinet valinet changed the title Incompatibility with AutoHotkey Win+Q combination does not work Aug 31, 2021
@Gaurav-Original-ClassicShellTester

Well it's the same as #3 so if you want to close the issue, please do :)

@valinet
Copy link
Owner

valinet commented Aug 31, 2021

Yeah, I don't mind, I will close them both for good soon =))) (hopefully)

valinet added a commit that referenced this issue Aug 31, 2021
* Instead of the overthinked and overcomplicated way the Win+X
  key combination was handled before, it now just sends a
  WM_CONTEXTMENU message to the Start button and Explorer takes
  care of the rest (I still haven't managed to figure out why the
  COM interface call did not work though)
* Added more info to IImmersiveMonitorService
@valinet
Copy link
Owner

valinet commented Aug 31, 2021

I fixed it in the latest build (22000.168.0.11), Win+Q is now free to map to whatever you'd like.

@valinet valinet closed this as completed Aug 31, 2021
@Gaurav-Original-ClassicShellTester
Copy link
Author

Oh wow thank you so much!!

@valinet valinet added Bug Something isn't working fixed labels Oct 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working fixed
Projects
None yet
Development

No branches or pull requests

2 participants