Dave in PNG Posted September 12, 2006 Share Posted September 12, 2006 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. Link to comment Share on other sites More sharing options...
jpm Posted September 12, 2006 Share Posted September 12, 2006 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 Link to comment Share on other sites More sharing options...
Dave in PNG Posted September 12, 2006 Author Share Posted September 12, 2006 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. Link to comment Share on other sites More sharing options...
sohfeyr Posted September 13, 2006 Share Posted September 13, 2006 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 Mine:Time Functions - Manipulate the system clock! | WinControlList (WinGetClassList++) | .Net Setup Wrapper, Detect or install .Net | Writing and using a VB .NET COM object in AutoItNot mine, but highly recommended:AutoItTreeViewExtension plugin | Menu code | Callback helper dll | Auto3Lib - Control the uncontrollable | Creating COM objects in AutoIt | Using .Net framework classes in AutoIt Link to comment Share on other sites More sharing options...
jpm Posted September 13, 2006 Share Posted September 13, 2006 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 EndFuncWhat 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 ... Link to comment Share on other sites More sharing options...
sohfeyr Posted September 13, 2006 Share Posted September 13, 2006 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. Mine:Time Functions - Manipulate the system clock! | WinControlList (WinGetClassList++) | .Net Setup Wrapper, Detect or install .Net | Writing and using a VB .NET COM object in AutoItNot mine, but highly recommended:AutoItTreeViewExtension plugin | Menu code | Callback helper dll | Auto3Lib - Control the uncontrollable | Creating COM objects in AutoIt | Using .Net framework classes in AutoIt Link to comment Share on other sites More sharing options...
jpm Posted September 13, 2006 Share Posted September 13, 2006 @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. Link to comment Share on other sites More sharing options...
Dave in PNG Posted September 13, 2006 Author Share Posted September 13, 2006 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. Link to comment Share on other sites More sharing options...
MHz Posted September 13, 2006 Share Posted September 13, 2006 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. Link to comment Share on other sites More sharing options...
sohfeyr Posted September 13, 2006 Share Posted September 13, 2006 In everyone's experience when these functions are wrong do they more often:1) Say the window exists when it doesn't2) 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? Mine:Time Functions - Manipulate the system clock! | WinControlList (WinGetClassList++) | .Net Setup Wrapper, Detect or install .Net | Writing and using a VB .NET COM object in AutoItNot mine, but highly recommended:AutoItTreeViewExtension plugin | Menu code | Callback helper dll | Auto3Lib - Control the uncontrollable | Creating COM objects in AutoIt | Using .Net framework classes in AutoIt Link to comment Share on other sites More sharing options...
Dave in PNG Posted September 13, 2006 Author Share Posted September 13, 2006 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. Link to comment Share on other sites More sharing options...
sohfeyr Posted September 14, 2006 Share Posted September 14, 2006 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 Mine:Time Functions - Manipulate the system clock! | WinControlList (WinGetClassList++) | .Net Setup Wrapper, Detect or install .Net | Writing and using a VB .NET COM object in AutoItNot mine, but highly recommended:AutoItTreeViewExtension plugin | Menu code | Callback helper dll | Auto3Lib - Control the uncontrollable | Creating COM objects in AutoIt | Using .Net framework classes in AutoIt Link to comment Share on other sites More sharing options...
Dave in PNG Posted September 15, 2006 Author Share Posted September 15, 2006 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? Link to comment Share on other sites More sharing options...
MHz Posted September 15, 2006 Share Posted September 15, 2006 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 Link to comment Share on other sites More sharing options...
Dave in PNG Posted September 17, 2006 Author Share Posted September 17, 2006 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) Link to comment Share on other sites More sharing options...
Dave in PNG Posted September 25, 2006 Author Share Posted September 25, 2006 And after a bunch of more days, my "missing window" error has completely disappeared. Thanks all! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now