Windows 10 suspends it's "windows store" apps in the background using superfetch/prefetch, even if you don't open them.
Commonly 'stored' apps are Photos, Mail, and Windows Store itself.
The problem is, if these apps are maximized last time they were used, and then windows 10 decides to preload them (while they stay suspended - not on taskbar or alt tab) then autohotkey still detects them as "open" and maximized.
This is breaking the main functionality of the feature, I feel.
I searched this forum and the bugs forum and could not find this reported. I thought I would post it here as it may be considered a new feature perhaps.
WinGetMinMax false detection windows 10 Topic is solved
Re: WinGetMinMax false detection windows 10
Yes, other window commands such as WinExist, etc, find these background windows
try it and see
...
...
Re: WinGetMinMax false detection windows 10
I know they detect them. The minimax function is the problem. It's detecting a window as maximised when it is not visible.
Re: WinGetMinMax false detection windows 10
- Does this work to tell you if the window is visible or not? If so, you could write your own custom function version of the WinGet-MinMax subcommand.
- There seem to have been a lot of problems with certain Windows 10 windows e.g. Calculator.
- Which command(s) detects them as 'open'?
Code: Select all
vWinIsVis := DllCall("user32\IsWindowVisible", Ptr,hWnd) ;1 = visible, 0 = not visible
- Which command(s) detects them as 'open'?
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: WinGetMinMax false detection windows 10
Just tried this.
The windows store has currently resurrected itself in a suspended state. I last left the window maximized before I closed it.
It does not appear in alt-tab or the taskbar or my dock.
Here is the process in task manager details tab:
The status is "suspended" but I cant target this with com commands because the status feature was never completed/implemented in windows.
If I open the store and then minimize it, Autohotkey then says the status is minimized.
Any ideas?
The windows store has currently resurrected itself in a suspended state. I last left the window maximized before I closed it.
It does not appear in alt-tab or the taskbar or my dock.
Here is the process in task manager details tab:
The status is "suspended" but I cant target this with com commands because the status feature was never completed/implemented in windows.
If I open the store and then minimize it, Autohotkey then says the status is minimized.
Any ideas?
Re: WinGetMinMax false detection windows 10
The Windows API (IsWindowVisible) reports that these windows are visible, so AutoHotkey treats them as such.
The Windows API reports the min/max state of these windows, and AutoHotkey merely returns it. I believe the min/max state returned is correct; if the window is made visible without also restoring/minimizing/maximizing it, it will be in that state.
Filtering out these windows requires using additional APIs which must be loaded and called dynamically as they are absent from some of the OS versions AutoHotkey supports. This filtering could have unforeseen consequences to the behaviour or performance of the majority of scripts (i.e. all scripts which use a command or function with WinTitle parameter, with some exceptions).
The simplest way to filter out these windows is to check for the DWMA_CLOAKED attribute with DwmGetWindowAttribute:Windows of suspended apps and windows on other virtual desktops return 2.
If we want to differentiate between suspended apps and windows on other virtual desktops, we can use IVirtualDesktopManager::GetWindowDesktopId (see IVirtualDesktopManager dllCall). My testing showed that only a suspended app returned a GUID with all zeroes. Whether one can rely on this is unknown. I have not tested the performance of this API, but I suspect it would be worse than DwmGetWindowAttribute (which takes about twice as long to call than IsWindowVisible with DllCall).
IVirtualDesktopManager::IsWindowOnCurrentVirtualDesktop (see Windows 10 - How to distinguish between "visible" and "invisible" windows) appears to return true for windows of suspended apps regardless of which desktop you are on.
The Windows API reports the min/max state of these windows, and AutoHotkey merely returns it. I believe the min/max state returned is correct; if the window is made visible without also restoring/minimizing/maximizing it, it will be in that state.
Filtering out these windows requires using additional APIs which must be loaded and called dynamically as they are absent from some of the OS versions AutoHotkey supports. This filtering could have unforeseen consequences to the behaviour or performance of the majority of scripts (i.e. all scripts which use a command or function with WinTitle parameter, with some exceptions).
The simplest way to filter out these windows is to check for the DWMA_CLOAKED attribute with DwmGetWindowAttribute:
Code: Select all
IsWindowCloaked(hwnd) {
; Resolve dwmapi\DwmGetWindowAttribute once only, for performance.
static gwa := DllCall("GetProcAddress", "ptr", DllCall("LoadLibrary", "str", "dwmapi", "ptr"), "astr", "DwmGetWindowAttribute", "ptr")
; DWMWA_CLOAKED := 14
return (gwa && DllCall(gwa, "ptr", hwnd, "int", 14, "int*", cloaked, "int", 4) = 0) ? cloaked : 0
; Return values:
; 0: not cloaked
; 1: cloaked by the application
; 2: cloaked by the shell
; 4: cloak value inherited from its owner
}
If we want to differentiate between suspended apps and windows on other virtual desktops, we can use IVirtualDesktopManager::GetWindowDesktopId (see IVirtualDesktopManager dllCall). My testing showed that only a suspended app returned a GUID with all zeroes. Whether one can rely on this is unknown. I have not tested the performance of this API, but I suspect it would be worse than DwmGetWindowAttribute (which takes about twice as long to call than IsWindowVisible with DllCall).
IVirtualDesktopManager::IsWindowOnCurrentVirtualDesktop (see Windows 10 - How to distinguish between "visible" and "invisible" windows) appears to return true for windows of suspended apps regardless of which desktop you are on.
Re: WinGetMinMax false detection windows 10
This always returns 0 in my testing. This part:
Always returns -2147024890
I am sending this to the full function you have written:
This returns 0 for all windows.
Running windows 10 fall creators update.
EDIT:
Removing the "ahk_id " part in front of the ID, it works now.
For some reason I need this part everywhere else in my code but not here.
Thanks!
Code: Select all
DllCall(gwa, "ptr", hwnd, "int", 14, "int*", cloaked, "int", 4)
I am sending this to the full function you have written:
Code: Select all
IsWindowCloaked("ahk_id " thisId)
Running windows 10 fall creators update.
EDIT:
Removing the "ahk_id " part in front of the ID, it works now.
For some reason I need this part everywhere else in my code but not here.
Thanks!
Re: WinGetMinMax false detection windows 10
you need the "ahk_id " prefix string only when using a hwnd in a WinTitle parameter of a CommandAshtefere wrote: EDIT:
Removing the "ahk_id " part in front of the ID, it works now.
For some reason I need this part everywhere else in my code but not here.
lexikos' function uses the hwnd directly, as does all of the microsoft win32 apis
Re: WinGetMinMax false detection windows 10 Topic is solved
I believe that satisfies @Ashtefere's request.v1.1.32.00
Changed commands and functions with a WinTitle parameter to treat cloaked windows as hidden.
Who is online
Users browsing this forum: No registered users and 28 guests