Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate

IfWinExist/Active /() reports false for active window


  • Please log in to reply
24 replies to this topic
  • Guests
  • Last active:
  • Joined: --

in one of my scripts i have a 1 sec run-once timer to double-check it, since it was failing so often. it still fails every once in a while which means that WinWaitClose fails 2 times, a second apart, while i'm looking at the window (IE7 tab in this case) that it is reporting as closed.


i caught it in the act - it just did it again with the script that i was referring to
and it's actually IfWinExist that is failing

here is the line listing with a few revelant comments:
209: Send,^{F4} (0.14)
210: WinWaitClose,\Sudokus.txt ahk_class TfPSPad.UnicodeClass,,2 (0.36)
this is the only window (tab) open in IE
211: IfWinExist,Web Sudoku - Billions of Free ahk_class IEFrame
212: WinActivate (0.13)
i saw the window go down fast and yet IfWinExist evaluates as true
217: Return (3.77)
165: ControlGet,ControlID,Hwnd,,Internet Explorer_Server1
this works for IE when other tabs are open
166: Send,^{F4} (0.03)
167: WinWaitClose,ahk_id %ControlID%,,2 (1.02)
it waits for another second (quite baffling) but doesn't time out
170: SetTimer,CheckWin,-1000
174: IfWinActive,\Sudokus.txt ahk_class TfPSPad.UnicodeClass
176: IfWinExist,ahk_class IEFrame,Web Sudoku - Billions of Free
177: Return (1.00)
IfWinExist evaluates as true even though the IE window has been closed for over a second at this point (probably over 2 sec)
196: Gosub,CheckWin2
174: IfWinActive,\Sudokus.txt ahk_class TfPSPad.UnicodeClass
176: IfWinExist,ahk_class IEFrame,Web Sudoku - Billions of Free
177: Return
and it still evaluates as true for a window that's long gone
Chris - are you absolutely certain beyond any doubt whatsoever that IfWinExist doesn't have a bug?

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
There could be bugs; but any bug seems unlikely to affect only one type of window (Internet Explorer).

Maybe it has something to do with DetectHiddenWindows being turned on (if you did turn it on). If not, maybe the OS sometimes reports the wrong status for this type of window.

You could try a direct call to the OS:
if (hwnd := DllCall("FindWindow", str, "IEFrame", uint, 0))
	MsgBox An IEFrame window exists (hwnd = %hwnd%).


  • Guests
  • Last active:
  • Joined: --
DetectHiddenWindows is Off - otherwise i would have posted that

thanks for the DllCall - but is IfWinExist different or a wrapper for it? - if it is different then i'll try it - please let me know

it's not just Internet Explorer - that's just the window that this script was dealing with this time that i could catch it in the act
if you will recall the previous window was a Customize Notifications dialog window from the 1st ListLines posting near the start of this thread
you said that you wanted to see it with a common window so i had to wait until i could catch it with one

and this is a very difficult thing to catch - i use this script several times a day and it's been over 3 weeks since it's done this - that is IfWinExist failing 2 times, a second apart. the else to the IfWinExist is ExitApp - so when it doesn't close with the IE window then i know that something is wrong - and what it is
when the 1st IfWinExist fails but not the 2nd one - which happens much more frequently - the script still closes so no ListLines and no proof that it happened (i watch the tray icon and when it hesitates for a second before blinking off i know why)
i've been using this script several times a day for over 2 years and it is rock-solid - tried and true - and it even usually closes with the last Web Sudoku tab with other pages in other tabs
so when this occasionally happens i already know the reason - a false positive from IfWinExist - always - it's never anything else - i've seen it in ListLines dozens of times

but most scripts aren't set up to catch it so when this happens, and it happens to everyone, most AutoHotkey users just assume that their code is at fault (which is true most of the time that a script malfunctions) and they'll be tearing out their hair trying to figure out what's wrong with their code when on this particular occasion nothing is at all - the code is fine - something else is failing

and i don't know how to test this beyond what i'm already doing - that will be up to any hardcore testing gurus (which i am not) that are interested
i hesitated for years to ask for help and my instincts re this were right - there's nothing wrong with my code - the problem is elsewhere - where no one can "help", but many would think that they could who would offer all kinds of (mostely untested) suggestions/solutions - all of them useless

i almost didn't post this at all - it grew out of a related post
my reason for posting is 2 fold:
- to alert you (Chris) to this issue and to see if it could possibly be AutoHotkey bugs
- to alert AutoHotkey users that this can and does happen and prove it with line listings
i've searched and read a lot of posts over the years and i havn't seen a hint of this anywhere. if it's there and i've missed it please let me know.

i've known that Windows has always been very buggy and screwed up, but this means that it's FUBAR.
tGf AutoHotkey - it helps keep this within tolerable limits. i probably couldn't stand to use this OS without it anymore.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
DllCall/FindWindow is different than IfWinExist because IfWinExist (and probably all window-finding commands) use EnumWindows(). In theory both methods should give the same answer.

Until a way can be found to reliably reproduce the behavior, it will probably remain unsolved. Perhaps a script could be written that opens and closes a simple window hundreds of times until the issue occurs.

If it winds up being a flaw in the OS, there might not be any complete solution.

Thanks.

  • Guests
  • Last active:
  • Joined: --
Chris - thank you so much for your thoughtful and timely responses and suggestion

...probably all window-finding commands use EnumWindows

does this include WinGet?

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Yes, WinGet calls WinExist() internally, which uses EnumWindows(). It seems that none of the windowing commands and functions call FindWindow().

DannyL
  • Guests
  • Last active:
  • Joined: --
All of us were I work use the same spreadsheet to update maintenance assignments. If one person is using the sheet others cannot. Well, I would frequently leave my desk with that sheet open blocking others and would get many complaints ;)

This I set out to fix with AHK. The idea is that if the sheet is open but inactive (out of focus) for some time OR if the computer is idle for some time, save and close the sheet.

It works most of the time but I find that it sometimes will be on my desktop, I'll check the Line Recently Executed page of AHK and find that it is not seeing the sheet open.

Below is the code in question.

Disclaimer: This is my first use of AHK. I really love it!!! Thank you.
BEGIN - Automatically shut the Maintainance forcast if not in use.
SetTimer, MaintForecast_AutoClose, 10000
Return

MaintForecast_AutoClose:
SetTitleMatchMode, 2
IfWinExist, Microsoft Excel - Mid Georgia Maintenance Schedule, ,[Read-Only],
{
   IfWinActive
   {
      MFinactive := 0
   }
   IfWinNotActive
   {
      MFinactive++
   }
   NoOneAtMachine := A_TimeIdlePhysical
   if(NoOneAtMachine > 600000 or MFinactive > 30)
   {
      WinActivate
      Send ^s^w
      Return
   }
}
Return
;END - Automatically shut the Maintainance forcast if not in use.


KalleW
  • Members
  • 31 posts
  • Last active: Jul 25 2010 10:17 PM
  • Joined: 09 Jun 2005
Are there any TOOLTIPs open on the screen??

If NO: forget this.

If YES: look at http://www.autohotke...pic.php?t=45409
(where the handle of the tooltip was returned / watched instead of the wanted window).

DannyL
  • Guests
  • Last active:
  • Joined: --
No tool tips are displayed.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
At least with some versions of Excel, I seem to remember that an open workbook might not be detectible, close-able, and/or activate-able if it isn't the active workbook of the Excel application. (If you have more than one workbook open, you can activate Excel and press Control-Tab to switch to the other workbook.)

There may be a setting/preference in Excel to change how it displays multiple workbooks. If not, maybe there is some other way to work around this such as activating Excel then sending a series of Control-Tab keystrokes to activate each workbook, one at a time.