Ciantic/VirtualDesktopAccessor

Window focus stays at previous virtual desktop

c0ffeeartc opened this issue · 6 comments

c0ffeeartc commented

When I switch worskpaces through hotkey - focus stays on the old workspace, and keypresses are received by previous window.
I have partial solution, that has other drawbacks

#u::
    DllCall(GoToDesktopNumberProc, Int, 0)
    Send, {ALT DOWN}{TAB}{ALT UP}
return
#i::
    DllCall(GoToDesktopNumberProc, Int, 1)
    Send, {ALT DOWN}{TAB}{ALT UP}
return
  • Brings focus to correct workspace, yay
  • Blinks
  • May work as swap two windows on current workspace. Hmm
  • Sometimes also swaps window on switching workspace.

Anyone else experienced issue, is there a better solution workaround ?

Ciantic commented

This is also an issue in the Windows 10 virtual desktop implementation. If I use "Win+Ctrl+Right" to switch back and forth, only the window where I left remains focused.

It would be better to open issues in Microsoft connect, if I could figure out where in there.

  • 👍1
Ciantic commented

See e.g. this: http://superuser.com/questions/1004074/windows-10-automatically-focus-windows-on-virtual-desktops it's known issue (one of many) in Windows 10 virtual desktop implementation.

Ciantic commented

I'm closing this, initial test shows this does something like that:

RegisterPostMessageHookProc := DllCall("GetProcAddress", Ptr, hVirtualDesktopAccessor, AStr, "RegisterPostMessageHook", "Ptr")
DllCall(RegisterPostMessageHookProc, Int, hwnd, Int, 0x1400 + 30)
OnMessage(0x1400 + 30, "VWMess")
VWMess(wParam, lParam, msg, hwnd) {
    ; ...
    Send !{Esc} ; ALT+Esc activates last window
}

EDIT: It seems like it activates wrong window at times, but the point remains, if someone finds a way to call "ALT+TAB" once in the same location it should work.

But it's not an issue in this DLL/wrapper itself, it's a missing feature in Windows 10 desktop implementation.

c0ffeeartc commented

Yes. I confirm that Ctrl+Win+Arrow loses focus.
Alt+Esc works great for me.

tom-bowles commented

I get this behaviour, but only with VirtualDesktopAccessor. I'm simply calling GoToDesktopNumber() (not using autohotkeys). Ctrl+Win+Arrow does not have this behaviour for me.

tom-bowles commented

I was able to resolve this by calling AllowSetForegroundWindow(ASFW_ANY) before calling GoToDesktopNumber(). Presumably AutoHotKey does this, but I had to do it explicitly.

  • 👍4