Nibbik Posted February 22, 2009 Share Posted February 22, 2009 The default _IEQuit()-function in the <IE.au3> library doesn't work properly when IE has an open dialog: IE won't close while having open dialogs, but _IEQuit() doesn't recognise that: it will only give an error on incorrect object type, bus as long as the given handle is an object is of correct type (IE browser window handle) it sends a close command and assumes succes, and moreof a problem it resets the handle to 0 so you won't be able to try again. I would like to suggest the following improvement: Func _IEQuit(ByRef $o_object) If Not IsObj($o_object) Then __IEErrorNotify("Error", "_IEQuit", "$_IEStatus_InvalidDataType") SetError($_IEStatus_InvalidDataType, 1) Return 0 EndIf ; If Not __IEIsObjType($o_object, "browser") Then __IEErrorNotify("Error", "_IEAction", "$_IEStatus_InvalidObjectType") SetError($_IEStatus_InvalidObjectType, 1) Return 0 EndIf ; While __IEIsObjType($o_object, "browser") $o_object.quit() WEnd $o_object = 0 SetError($_IEStatus_Success) Return 1 EndFunc ;==>_IEQuit Using While...WEnd it will try and try again until it succeeds. I noticed this problem when I tried to use a hidden IE-window for printing formatted output, using HTML for formatting and using a <BODY onload="java script:window.print()"> tag to force a print dialog from the IE-window. I will allow the IE window a Sleep(1000)-timeout for generating the print dialog and then start closing attempts using this modified _IEQuit()-function, so my AutoIt script continues as soon as the IE print-dialog is closed. With the original function the script continued directly - no problem - but the window wasn't closed because it couldn't at the time the command was given, and I couldn't correct later on since the handle was reset to 0, so after some print commands I would end up with several resource-consuming hidden IE windows. Reactions please: is this an improvement or not? (and if not: why not, or how to do it better?) Link to comment Share on other sites More sharing options...
dantay9 Posted February 22, 2009 Share Posted February 22, 2009 That would use up a lot of CPU by using that loop. It also has the potential to become caught and hang there. That's another problem. Link to comment Share on other sites More sharing options...
DaleHohm Posted February 22, 2009 Share Posted February 22, 2009 Thanks for your analysis. I was unaware of this behavior if a dialog is open. In my opinion however, your solution is not viable. The way you have it written can create an infinite hang of the script and even with a timeout it will not be obvious to the user what needs to be done or what is causing the hang. The quit method does not have a return value so there's nothing we can directly to check status after the call. It is also telling that this code has been out there for several years in IE.ai3 and this is the first report of the issue. I believe that the cure prescribed will cause more trouble that the issue as it stands. Since you looked in Func _IEQuit you can see that it does little more than call the $oIE.quit method. If this issue is causing you trouble, I suggest you either call .quit directly or you save off your borwser object variable ($oIE2 = $oIE) before calling _IEQuit that you can keep the object reference and do further tests on it your self. Dale Free Internet Tools: DebugBar, AutoIt IE Builder, HTTP UDF, MODIV2, IE Developer Toolbar, IEDocMon, Fiddler, HTML Validator, WGet, curl MSDN docs: InternetExplorer Object, Document Object, Overviews and Tutorials, DHTML Objects, DHTML Events, WinHttpRequest, XmlHttpRequest, Cross-Frame Scripting, Office object model Automate input type=file (Related) Alternative to _IECreateEmbedded? better: _IECreatePseudoEmbedded Better Better? IE.au3 issues with Vista - Workarounds SciTe Debug mode - it's magic: #AutoIt3Wrapper_run_debug_mode=Y Doesn't work needs to be ripped out of the troubleshooting lexicon. It means that what you tried did not produce the results you expected. It begs the questions 1) what did you try?, 2) what did you expect? and 3) what happened instead? Reproducer: a small (the smallest?) piece of stand-alone code that demonstrates your trouble 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