WinWait and WinGetPos

[Dave in PNG]

I have a script that works fine almost all day, then about once a day or even less frequently, it will fail. Here is the section of code involved:

if (WinWait($TitleModem,"",60) = 1) Then
    $size = WinGetPos($TitleModem)

(All of the code would be pages worth. I hope this is enough to get some suggestions.)

WinWait returns '1' but then WinGetPos returns 0 and @error is set to '1' (window not found).

How can WinWait find it but WinGetPos not? I guess it's possible the windows closed during the two lines, but that would have to be pretty fluky.

Any ideas?

Thanks.

[jpm]

if (WinWait($TitleModem,"",60) = 1) Then
    if NOT WinExists($TitleModem) Then MsgBox(0,"STRANGE !!!","Windows has disapeared")
    $size = WinGetPos($TitleModem)

See if really something strange occured

[Dave in PNG]

I tried the above suggestion:

if (WinWait($TitleModem,"",60) = 1) Then
    if NOT WinExists($TitleModem) Then Send_A_Cry_For_Help("The window was here, now it's gone.")
    $size = WinGetPos($TitleModem)

(Send_A_Cry_For_Help is a function I wrote to send an email to me. This is part of a monitoring system for a server.)

The "If" was satified and went to WinExists which didn't find the window. What gives?!?

A little more background: This section of code gets run every five seconds, 24 hours a day. About once a day at random times, WinWait seems to get satisified, but then the very next line of code can't find the window.

I have another section of code using WinWait and WinGetPos that will fail in a similiar fashion but much less often.

I'd really rather not have to write another WinWait substitute or write around it.

Thanks.

[sohfeyr]

I ended up writing a wrapper around WinExists. For whatever reason, WinExists was returning True at strange times. I know this isn't exactly the same as your problem, but it demonstrates the principle that ended up working for me.

Func _WinExists($Title, $Text)
    Local $val = WinExists($Title, $Text)
    If WinGetHandle($Title, $Text) = WinGetHandle("Doesn't bloody exist") then $val=0
    Return $val 
EndFunc

[jpm]

I ended up writing a wrapper around WinExists. For whatever reason, WinExists was returning True at strange times. I know this isn't exactly the same as your problem, but it demonstrates the principle that ended up working for me.

Func _WinExists($Title, $Text)
    Local $val = WinExists($Title, $Text)
    If WinGetHandle($Title, $Text) = WinGetHandle("Doesn't bloody exist") then $val=0
    Return $val 
EndFunc

What does your script is no more than calling twice WinExists for the same windows.

The Wingethandle is calling internally WinExists.

I don't know which situation has been solved with such UDF. It is true that WinExist will not garanty that the windows will exist when executing the next statement. Checking twice does not help so much the logic of the script.

But who knows perhaps you go around an hidden bug of AutoIt. I would be very surprised as the function has been used a lot of time by a lot of people. A bug can still be there ...

[sohfeyr]

What does your script is no more than calling twice WinExists for the same windows.

That's what I thought. Then WinExists started giving me bad answers about a month ago, so I did the workaround using WinGetHandle. That worked, so I attached ConsoleWrite to each line and they sometimes give different answers. The second line is usually closer to reality.

Seriously, I don't know why this scrap works, just that it solved my particular problem. It isn't anywhere close to the entire function (which has additional checks and logs that aren't going to be relevant to anyone else), but it is the heart of it.

I would be very surprised as the function has been used a lot of time by a lot of people.

I know! I love AutoIt, but if I was to write a journal of just this week, it would be titled "A Study in Artificial Capriciousness"!

Jpm, maybe you can tell me... is it possible to create a neural network in AutoIt by accident, and if so, could it be, like, insane?

You're right, if it was a bug in AutoIt, it would have been caught long, long ago. But in all fairness, I've been asking it to do some strange things with... unusual windows. (Sorry, I'm not allowed to be more specific.) What can I say? That's what works at the moment. If anyone wants it, they can have it.

I've had to wrap a lot of window-related functions. Timeouts not working, windows claiming to exist after being closed, and actually needing a 5-level custom WinWaitClose function, and a WinWaitActivate that decides not to work after 4 on Fridays on half our machines but does fine the rest of the week... Almost as if the functions knew how much we depend on them and desire to exercise power over us... I finally got WinWaitActivate stapled down today and most of the rest fell into line.

Yeah, yeah, go ahead and laugh.

Really, it's not all that bad; I had to wrap them anyways for logging purposes, but every couple of months or so things that had been working fine turn on us. In isolation, the commands work great. In context, it can become a maintenance nightmare. I'm looking seriously at refactoring my code (if such a thing can be said in a scripting language) and implementing a remote diagnostics system.

Well, that's me venting. Thanks for listening.

[jpm]

@sohfeyr

Thank you for your comments.

I will be interested see your wrapper functions and perhaps the context where you think they have been successful.

The only I know if the difficulty to have a WinWaitActive with the windows loosing the focus.

If you don't want to post yours wrappers just PM me, I really want to know if there is not a AutoIt hidden bug.

[Dave in PNG]

So...

In everyone's experience when these functions are wrong do they more often:

1) Say the window exists when it doesn't

2) Say the window does not exist when it does

I guess I could ask five times and take the majority opinion. This is kind of a bummer approach.

If this is a bug (a big 'if') but I can't reproduce it, where do I go from here?

Wrapping the function in all sorts of checks is possible but hardly a plesant thought.

I do love AutoIt though.

[MHz]

If this is a bug (a big 'if') but I can't reproduce it, where do I go from here?

There is a bug that cannot be reproduced so does it even exist?

Based on 2 lines of code that does not mention Opt()'s use, what the value of $TitleModem is, whether AdlibEnable() is used or any other influence...Hmm.

[sohfeyr]

In everyone's experience when these functions are wrong do they more often:

1) Say the window exists when it doesn't

2) Say the window does not exist when it does

@JPM: Check your mailbox.

@Dave: I've seen it happen both ways, but mostly #1.

I'm wondering if extensive use of tooltips (for debugging) are causing some of the problems I've been having with windows not staying active. Any ideas there? If a tooltip has just appeared, could WinGetPos("","") or similar commands pick up the tooltip by accident?

[Dave in PNG]

There is a bug that cannot be reproduced so does it even exist?

Based on 2 lines of code that does not mention Opt()'s use, what the value of $TitleModem is, whether AdlibEnable() is used or any other influence...Hmm.

$TitleModem is a string that is not changed anywhere and no AdLib stuff being done. Or tooltips. In fact, this program has no GUI. it just sits in the tray looking and a window and restarts the program if the window disappears.

[sohfeyr]

There is a bug that cannot be reproduced so does it even exist?

Today, the code I posted above went renegade and returned True for nonexistant windows - any and all nonexistant windows! It returned True ALL THE TIME.

;----------------------------------------------
; Implemented 8/22/06, Stopped working 9/13/06. False True on bogus windows
;   Local $val = WinExists($Title,$Text) 
;   If WinGetHandle($Title,$Text) = WinGetHandle("Doesn't bloody exist") then $val=0
;----------------------------------------------
oÝ÷ Ù8^~e£§0z÷«±ç¦²Ú0¢¹ºÚ"µÍËKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKBÈ[[Y[YÌLËÌ
ØØ[   ÌÍÝË    ÌÍÝ[HYÝ
    ÌÍÕ]OI][ÝÉ][ÝÈ[  ÌÍÕ^I][ÝÉ][ÝÊH[RYÚ[Ù]]J    ÌÍÕ]K    ÌÍÕ^
IÉÝÌ[    ÌÍÝ[HB[YY    ÌÍÝ[L[BSØØ[    ÌÍÕÚ[ÝUÚ[Ý

BIÌÍÕ]OTÝ[Ê    ÌÍÕ]JBQÜ    ÌÍÞHHÈ  ÌÍÕÚ[ÝÌVÌBBRY    ÌÍÕ]HHÝ[Ê  ÌÍÕÚ[ÝÉÌÍÞVÌWJH[  ÌÍÝ[LHÈHÈXÛÙÛ^H[ÂBRY   ÌÍÕ]HH   ÌÍÕÚ[ÝÉÌÍÞVÌH[    ÌÍÝ[LHÈH]HX]ÚBRYÝ[Ò[Ý   ÌÍÕÚ[ÝÉÌÍÞVÌK ÌÍÕ]JH   ÝÈ[   ÌÍÝ[LHÈH]HÝXÝ[ÈX]ÚBRY   ÌÍÕ^ ÉÝÈ  ][ÝÉ][ÝÈ[BBRYÝ[Ò[ÝÚ[Ù]^
    ÌÍÕÚ[ÝÉÌÍÞVÌWJK   ÌÍÕ^
H   ÝÈ[   ÌÍÝ[LHÈH^X]ÚBQ[YS^[Y]  ÌÍÝ[ËKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKB

[Dave in PNG]

In looking through the help file, I found this:

WinWaitDelay - Alters how long a script should briefly pause after a successful window-related operation.

Time in milliseconds to pause (default=250).

I can understand why the default is a quarter of a second, but I'm wondering if during that 250mS if my window doesn't disappear. The window I'm looking for is supposed to disappear a few times an hour. (It's when it doesn't re-appear that the AutoIt script has to act.)

I added Opt("WinWaitDelay", 10) to my script to see if my errors are reduced or disappear.

Does this sound plasible?

[MHz]

That is the delay after the window first appears. Take it down to 0 if you like. If possible, you could log the titles. This log may help to explain why some windows do come and then vanish.

Perhaps an ini may suit with using the Opt('WinWaitDelay', 0)

if WinWait($TitleModem, "", 60) Then
    _LogTitle(WinGetTitle($TitleModem))
    $size = WinGetPos($TitleModem)  

Func _LogTitle($Title)
    $ini_read = Int(IniRead(@ScriptDir & '\WinTitles.ini', 'List', $Title, '0'))
    If $ini_read = 0 Then
        $ini_read = 1
    Else
        $ini_read += 1
    EndIf
    IniWrite(@ScriptDir & '\WinTitles', 'List', $Title, $ini_read)
EndFunc

[Dave in PNG]

Just to let everyone know, after a few days of no more "where did my window go" errors, I am cautiously optomistic that changing the WinWaitDelay option to nearly zero may have resolved my problem.

Opt("WinWaitDelay", 10)

[Dave in PNG]

And after a bunch of more days, my "missing window" error has completely disappeared.

Thanks all!