AutoHotkey Community

sometimes a script doesn't work correctly and when i look at the ListLines a IfWinExist/Active /WinExist/Active() statement evaluates false for a window that i'm looking at

i haven't reported this because it only happens sporadically (but often enough to be annoying) and i don't know how to reproduce it. the only thing that i've noticed is that it seems to happen more when a window is switching or closing, or a new one is comming up - i.e. when windows are changing

is this an AutoHotkey bug?

Judging by the description you gave, it sounds like you are asking if a window is present a fraction of a second before it was registered as such.

You may want to strategically place one of two things:
1. WinWait (or WinWaitActive) - preferred
2. Sleep

It does not sound like a bug, but I may be wrong.

_________________
Sector-Seven - Freeware tools built with AutoHotkey

clarification:
a window that i'm looking at
could read:
a window that i'm using and looking at i.e. the active window

but doesn't really need to be because even with a new window that's coming up, it's long since registered (a second or 2) by the time you see the gui

the best thing would be, when you post your code...

post the code - otherwise it's impossible to say whether the bug is in AHK rather than your scripting lest other analogous reports emerge...

_________________
Hardware: 1.8 GHz laptop with 4 GB ram, Windows XP/SP3
Software: Prevx, Privatefirewall, KeyScrambler.

There are definitely times when there is no active window at all. In addition, it's conceivable that window animation (e.g. minimize/maximize) could give unexpected results until the animation is complete. I seem to remember that this is one of the original reasons for having SetWinDelay.

If the problem persists, you could try a higher setting for SetWinDelay such as: SetWinDelay 500

If that doesn't help, if you can ever find a script that reproduces the problem, please post it here.

Thanks.

this just in:

632: IfWinExist,Customize Notifications ahk_class #32770
633: ControlClick,OK,,,,,NA (0.03)
634: WinWaitClose,,,10 (0.13)
635: IfWinExist,Customize Notifications ahk_class #32770
636: MsgBox,32,%0_ScriptName% - %A_LineNumber%,'Customize Notifications' still exists (11.83)

it seems to be happening this way more than the other - false reporting of windows existing when they've closed, or at least after being reported to be so by WinWait*. sometimes it seems as if WinWait is working correctly. (in this case it clearly isn't)

in a related but separata issue - ControlClick,OK worked this time but the several times previous to this (in the last hour) it's been pushing the &Restore Defaults button. (should this be a seperate post?)

There are some notes on the ControlClick page about reliability:


If the problem with WinWaitClose persists, maybe try it with a simpler window like Notepad to ensure there really is a bug. This would also help to reproduce the issue on other PCs.

Thanks.

typo alert -

it seems to be happening this way more than the other - false reporting of windows existing when they've closed, or at least after being reported to be so by WinWait*. sometimes it seems as if WinWait is working correctly. (in this case it clearly isn't)

should read:

it seems to be happening this way more than the other - false reporting of windows existing when they've closed, or at least after being reported to be so by WinWaitClose. sometimes it seems as if WinWaitClose isn't working correctly. (in this case it clearly isn't)

here is my solution for now for the WinWaitClose part of the problem
i just put this together with only some preliminary testing (more testing later if needed)

unlike in the listing above, IfWinExist will always evaluate false after this function unless it times out

WinWaitClose is not known to have any bugs; in fact, all it does is call WinExist() in loop. Furthermore, it shares the same code with WinWait, ClipWait, and some other waiting commands. So if WinWaitClose has this bug, various other commands should also have the same bug. But since these commands have been in use for over 5 years, it's hard to imagine they aren't reliable.

So if you still have reason to believe that WinWaitClose isn't working properly, there would need to be some way to reproduce it (perhaps using a common window like Notepad).

Thanks.

then IfWinExist and WinExist() returned an opposite value for the same window, so one of them has a bug

the WinExist() in WinWaitClose had to incorrectly return false to break the loop (which surprised me because the Customize Notifications window was still showing) and in the next line IfWinExist correctly returned true for the same window

i've already stated that i don't know how to reproduce this problem - you probably need a hardcore testing guru for that (which i am most definitely not)

the listing was the 1st time after your (Chris) post that i was able to catch it in the act - i was debugging a script that would normally already be closed and therefor no ListLines.   most of my scripts are context sensitive and load/close with a window/group of windows, and i have to put them in debug mode to be able to see ListLines after their windows are gone.

there have been many times over the course of at least a couple of years that i have seen WinWaitClose return true (continue without timing out) in ListLines when the window still existed/showed (especially with IE7 with tabs).  it's been a big enough problem that 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 believe that IE7 is a "common window" - i don't use NotePad

i will post more lines when i can catch a script in the act again

Internally IfWinExist and WinExist() call the same code:
IfWinExist: if_condition = (WinExist(*g, FOUR_ARGS, false, true) != NULL)
WinExist(): WinExist(*g, param[0], param[1], param[2], param[3], false, true)

Therefore, what you're probably seeing is some kind of split-second timing issue where the OS in one instant reports that the window exists, but in the next instant that it doesn't exist. Perhaps this can happen if an application (or the OS) recreates a window by destroying and recreating a nearly-identical window. I'm not sure why it would do that, but stranger things have happened. Maybe it has something to do with Vista Aero or process privileges (e.g. admin rights).

If you or anyone else ever finds out more about it, please post here.

Thanks.

very strange


i thought that's the case until some script behavior seemed to indicate otherwise (it makes no sense for them to be different)

is there any possibility that WinWaitClose after ControlClick and without parameters is resetting LFW?

would there be any advantage to change it to:
634: WinWaitClose,Customize Notifications ahk_class #32770,, 10

the only reason for IfWinExist in line 632 is to set it, and it was faster/easier in PSpad to dup the line in 635

i'm running XP

It seems unlikely, but if you suspect it's true, it might not be hard to make a script that tests the behavior against simple windows like Notepad or Calculator.

That would be more reliable if there's any chance that the last found window has been destroyed or recreated since it was set.