WinExist/IfWinExist issue with ShellExperienceHost

[Noesis]

I've encountered issues detecting windows within ShellExperienceHost.exe (Windows 10). Not really sure if this is a deliberate limitation due to these windows always existing or if it's actually a bug.

Essentially, WinExist() and IfwinExist always fail, unless the window handle is also passed as part of the window Identifier. Not sure if it's always been this way, or new since 1.1.27.03.

I wrote the following, to investigate the issue, which should also serve as a proof of concept. There are comments in below code for results on variations. It's just a basic script which should display a tooltip whenever it detects the window on a LButton press. The idea is to open windows you know should work, i.e. with a class = "Windows.UI.Core.CoreWindow" and/or belonging to ShellExperienceHost.exe, (eg Start Menu, Jump Lists, Volume Control, Network Connections), and then click inside them (ideally on a blank section that does nothing), to see what is/isn't detected.

Code: Select all

CoordMode, Tooltip, Screen
SetTitleMatchMode, 1
txt := ""
Esc:: Tooltip
~LButton::
DetectHiddenWindows, On
;These Never work
If WinExist("ahk_class Windows.UI.Core.CoreWindow ahk_exe ShellExperienceHost.exe")
	txt .= "ahk_class Windows.UI.Core.CoreWindow ahk_exe ShellExperienceHost.exe Detected`n"
If WinExist("ahk_class Windows.UI.Core.CoreWindow")
	txt .= "ahk_class Windows.UI.Core.CoreWindow Detected`n"
If WinExist("ahk_exe ShellExperienceHost.exe")
	txt .= "ahk_exe ShellExperienceHost.exe Detected`n"
If WinExist("Volume Control")
	txt .= "Volume Control Detected`n"
If WinExist("Network Connections")
	txt .= "Network Connections Detected`n"
IfWinExist ahk_exe ShellExperienceHost.exe
	txt .= "non function ShellExperienceHost.exe`n"
IfWinExist ahk_class Windows.UI.Core.CoreWindow
	txt .= "non function Windows.UI.Core.CoreWindow`n"
	
;These also never work (thought they might given start as title only entry below)
If WinExist("Start ahk_class Windows.UI.Core.CoreWindow ahk_exe ShellExperienceHost.exe")
	txt .= "Start Menu with Class & Exe Detected"
If WinExist("Start ahk_class Windows.UI.Core.CoreWindow")
	txt .= "Start Menu with Class Detected"
If WinExist("Start ahk_exe ShellExperienceHost.exe")
	txt .= "Start Menu with Exe Detected"
	
DetectHiddenWindows, Off
;If DetectHiddenWindows not turned off, following start as title is always detected, when off it's never detected.
If WinExist("Start")
	txt .= "Start Menu Detected`n"
	
;Following all work correctly (i.e. if the window handle is also passed):
MouseGetPos,,,win,ctl
If WinExist("ahk_class Windows.UI.Core.CoreWindow ahk_exe ShellExperienceHost.exe AHK_id " win)
	txt .= "ahk_class Windows.UI.Core.CoreWindow ahk_exe ShellExperienceHost.exe  AHK_id %win% Detected`n"
If WinExist("ahk_class Windows.UI.Core.CoreWindow AHK_id " win)
	txt .= "ahk_class Windows.UI.Core.CoreWindow AHK_id %win% Detected`n"
If WinExist("ahk_exe ShellExperienceHost.exe AHK_id " win)
	txt .= "ahk_exe ShellExperienceHost.exe  AHK_id %win% Detected`n"
If txt
{
	tooltip, %txt%,0,0
	txt := ""
}
Return

[lexikos]

It is not a "deliberate limitation" of AutoHotkey, but it is a consequence of some bizarre and probably deliberate design choices by Microsoft in recent years. Keep in mind that WinExist is built on top of the Win32 API, and was designed over a decade ago. It is limited to whatever the Win32 API gives it.

I'm not sure about this particular window, but I was aware that there have been some "special" windows since Windows 8 which are not "seen" by the EnumWindows function (the backbone of WinExist).

When you pass ahk_id, WinExist does not need to enumerate windows; it just calls IsWindow to confirm the ID is valid, and then checks the other criteria.

Another issue is "DWM cloaking", which makes a window completely invisible but IsWindowVisible will still return true, so WinExist will find it regardless of DetectHiddenWindows. This has been discussed in another topic. It is used by Windows 10's virtual desktops and undoubtedly other things (since the DWMWA_CLOAKED attribute was added in Windows 8).

[Noesis]

"deliberate limitation" was a poor choice of words on my part, I meant "known limitation" but for some reason the term escaped me at the time. Anyway thanks for the explanation, makes sense as it is one of those "modern/universal" whatever MS calls it these days, type of interfaces, hence it would fall into the "special" category.

The "window" itself is to do with many but not all of the pop-ups invoked from the win 10 taskbar (the title changes but the class/exe are the same). i.e. Things like Volume Control icon, Network Icon, Clock, Action Center, Start Menu, Jump lists. But some areas are different like the notification overflow window.

It's not a big deal as they all seem to be forced to become the active window when they show, and don't show when they become inactive, so WinActive and other WinGet commands with A as the Wintitle can be used on them.