Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate

IfWinExist/Active /() reports false for active window

Started by Guest , Apr 08 2009 12:26 AM

  • Please log in to reply
24 replies to this topic
  • Guests
  • Last active:
  • Joined: --
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?
#1 - Posted 08 April 2009 - 12:26 AM
Icarus
  • Members
  • 851 posts
  • Last active: Jan 02 2012 11:17 AM
  • Joined: 24 Nov 2005
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.
#2 - Posted 08 April 2009 - 10:11 AM
Sector-Seven - Freeware tools built with AutoHotkey
  • Guests
  • Last active:
  • Joined: --
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
#3 - Posted 08 April 2009 - 05:11 PM
Andi
  • Members
  • 195 posts
  • Last active: Apr 18 2014 05:03 PM
  • Joined: 11 Feb 2005
the best thing would be, when you post your code...
#4 - Posted 09 April 2009 - 01:38 AM
pajenn
  • Members
  • 391 posts
  • Last active: Feb 06 2015 07:57 AM
  • Joined: 07 Feb 2009

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?


post the code - otherwise it's impossible to say whether the bug is in AHK rather than your scripting lest other analogous reports emerge...
#5 - Posted 09 April 2009 - 10:28 AM

Hardware: fast laptop with SSD
Software: Win 7 Home Premium 64-bit, android for phone and tablet

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.
#6 - Posted 10 April 2009 - 12:24 PM
  • Guests
  • Last active:
  • Joined: --
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?)
#7 - Posted 16 April 2009 - 09:51 AM
Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
There are some notes on the ControlClick page about reliability:

To improve reliability -- especially during times when the user is physically moving the mouse during the ControlClick -- one or both of the following may help:

1) Use SetControlDelay -1 prior to ControlClick. This avoids holding the mouse button down during the click, which in turn reduces interference from the user's physical movement of the mouse.

2) Specify the string NA anywhere in the sixth parameter (Options) as shown below:

SetControlDelay -1
ControlClick, Toolbar321, WinTitle,,,, NA
"NA" avoids marking the target window as active and avoids merging its input processing with that of the script, which may prevent physical movement of the mouse from interfering (but usually only when the target window is not active). However, this method might not work for all types of windows and controls.

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.
#8 - Posted 16 April 2009 - 11:05 AM
  • Guests
  • Last active:
  • Joined: --
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)
#9 - Posted 16 April 2009 - 04:07 PM
  • Guests
  • Last active:
  • Joined: --
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( WinTitle = "", Seconds = 0)
	{
	StartTC := A_TickCount
	While WinExist(WinTitle) and (Seconds = 0) + (A_TickCount < (StartTC + (1000 * Seconds)))
		sleep A_WinDelay
	a := (Seconds = 0) + (A_TickCount < (StartTC + (1000 * Seconds)))
	if a = 0	;	it timed out
		ErrorLevel := Seconds
	return a 	;	1/true on success (WinTitle no longer exists), 0/false if it still exists after Seconds seconds
	}

if WinWaitClose(WinTitle, 10)
	a = %WinTitle% is closed
else
	a = %WinTitle% is not closed after %ErrorLevel% seconds

#10 - Posted 17 April 2009 - 02:55 PM
Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.
#11 - Posted 18 April 2009 - 01:04 PM
  • Guests
  • Last active:
  • Joined: --
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
#12 - Posted 20 April 2009 - 07:02 PM
Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
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.
#13 - Posted 21 April 2009 - 11:47 AM
  • Guests
  • Last active:
  • Joined: --
very strange

Internally IfWinExist and WinExist() call the same code

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
#14 - Posted 22 April 2009 - 11:20 PM
Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

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

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.

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

That would be more reliable if there's any chance that the last found window has been destroyed or recreated since it was set.
#15 - Posted 23 April 2009 - 11:31 PM
Back to Issues
  1. AutoHotkey Community
  2. → AutoHotkey
  3. → Suggestions
  4. → Issues