BUG when opening a folder or cmd

[micoro]

OS: Window 10 (1809)

Minor bug. explorer/folder navigation isn't managed on opening. You need to move the window so that miguruWM sees it.

When using Win+E to navigate folders, the new window is not managed/tiled. Same when opening a folder through Run (Win+R). I mean folders like shell:startup or %appdata%. Same when opening a folder through the start menu. Same when opening a folder with right click and then "open folder in new window".

Same with CMD: when opening from start, from Run (win+R) or double clicking a *.cmd.

I also tried a couple other option with Run:

• regedit worked fine
• ms-settings: worked fine

[imawizard]

Thanks for the report.

I can't really reproduce your described behaviour, though. Could you test whether the explorer window is actually not getting managed by changing the layout immediately after it popped up? (Just press the shortcut for "tall" layout, even if it's already the "tall" layout; SetLayout() will retile all managed windows)

Because for me, explorer windows are not getting ignored, however, sometimes there seems to be a timing issue, resulting in misplacement like here:

[micoro]

Can confirm. The window is not managed. It does not retile and I can't focus it with Miguru.FocusWindow().

If I click on the folder icon in the taskbar Miguru sees the window and retiles it.

Note: I am on windows 10 and is kinda old build (1809). Can't upgrade this PC. When I am home I till test it on windows 11 but it won't be until next week. I edited the first post. It may be a problem linked to the old build? In that case I don't think it's worth any attention.

[imawizard]

Could you maybe test this issue again with the newest commit by

1. replacing teams.exe with explorer.exe in events.ahk and uncommenting the respective lines
2. executing $env:AHK_LOG = "trace"; autohotkey .\example.ahk
3. opening the explorer again with Win-E and check whether the log says anything about the specific window

[micoro]

Currently I get this error from AutoHotKey:

MiguruWM-Start.ahk is how I have renominated the example.ahk. In this test I was using "Teams.exe" to have the same usecase as you.

---

Anyway I tried to do some test without that filter. The Trace was hardly legibile but the problem may be that when a window is created the desktop is not immediately assigned.

Anyway It may be linked to the old build of windows 10 I am running (1809). In a couple of month I should have a new (updated) PC. It's better to wait for that and see if the problem is still there.

---

BTW, the new version seems to be working fine. The customizations on the code that I did are not needed anymore.

Question: I have seen that there are a couple of files that seems to still have ahk V1 code. Is that correct? (ex: IUnknown.ahk)

[imawizard]

Oh yeah, I forgot to wrap it in try:

try {
    if StrLower(WinGetProcessName("ahk_id" hwnd)) !== "teams.exe" {
        return
    }
} catch {
    return
}

Without filtering like that, there are just too many events.

Also I'm atm investigating an issue where a new WS_POPUP window (WinSpy64.exe) sometimes get picked up and sometimes not, which is probably related to yours (although it doesn't happen with explorer windows for me):

Apparently, IVirtualDesktopManager::GetWindowDesktopId is racy. Even though it's called after the window's shown-event, it sometimes throws E_ELEMENT_NOT_FOUND instead of returning the actual desktop guid for WinSpy64.exe (logs [TRACE] Ignoring: unknown desktop). As for teams notifications, for me it sometimes works correctly and sometimes returns an empty guid (logs [TRACE] Desktop not yet assigned).

So far I see no other way to discriminate between an actual invalid return value and a false one than to retry after a brief delay.

I might check out other WMs (which ones were using Windows' native virtual desktops again?) whether they pick up these windows reliably, maybe I'm doing a mistake somewhere or maybe it's due to some COM/threading internals of AutoHotkey.

---

Not on the ahk-v2 branch, which part do you mean?

[micoro]

Seems very likely. [TRACE] Ignoring: unknown desktop is the log I got for the new opened window. I will later try again with the try wrapper to see if I have a cleaner log that I can post here.

Question: when the desktop is "unknown" can you force the current desktop in some way? Or that could cause problem with windows that should actually have an undefined desktop?

---

Line 28: classes.Push(%proto.__Class%) The % is not from AHK v1?

Also other files with % are ComObjectImpl.ahk and InterfaceWrapper.ahk

[imawizard]

Question: when the desktop is "unknown" can you force the current desktop in some way? Or that could cause problem with windows that should actually have an undefined desktop?

Could result in an inaccurate representation of the windows within the workspaces-array. First I'll add a retry and see if it improves reliability.

The % is not from AHK v1?

It's also part of v2's syntax, but with different semantics: it's used for dereferencing VarRefs and for dynamically accessing an object's properties.

[micoro]

I changed my PC a week ago and I have a more recent version of Win10. I don't know if the problem was the build of windows or something else but I can say that currently the new windows are managed immediately.

If you want I think this issue could be closed?

[imawizard]

Good to hear, I'll close this then.

Btw I've added a delayed re-try that on my machine now picks up the WinSpy64.exe-window I mentioned above in case the first GetWindowDesktopId call didn't work.