LibrariesIE.au3

[DaleHohm]

File Name: IE.au3

File Submitter: DaleHohm

File Submitted: 27 Mar 2013

File Category: Libraries

Title: Internet Explorer Automation UDF Library for AutoIt3

Filename: IE.au3

Description: A collection of functions for creating, attaching to, reading from and manipulating Internet Explorer

Author: DaleHohm

Version: T3.0-0

Last Update: 9/3/12

Requirements: AutoIt3 3.3.9 or higher

This version is checked into the development stream for the next AutoIt beta release, but will work with the most recently released V3.3.9.x beta.

I am releasing it here so that it can get some testing now and help some people with some of the issues it fixes in the realm of COM error handling (and "the WEND error").

This file will be removed when it is included in a public beta release.

Dale

[DaleHohm]

Please test this IE.au3 include with the latest AutoIt beta release (3.3.9.x).

It takes advantage of COM errors no longer being fatal in the beta version and fixes the "WEND" error that some users have started experiencing in _IELoadWait in the past year or so.

It also contains some small bug fixes and one new enhancement (see base note).

Please discuss anything that needs to be discussed about it here.

Dale

[BrewManNH]

This UDF still has the same bugs reported in #2320, the return values are wrong in certain cases.

If $f_wait Then
    _IELoadWait($o_object)
    Return SetError(@error, 0, -1)
EndIf

If _IELoadWait returns an error, the return value from this section is going to be wrong. The functions return -1 as a success value, and if you're not looking at the @Error value returned and only looking to the return value, you're not going to see that there was an error.

[DaleHohm]

@BrewManNH, this is code checked in 6 months ago and unfortunately, I was unaware of the ticket you created 4 weeks ago.

That said, this is not a code bug (although there is an issue with the documentation) - it is working as designed and intended.

The special circumstance here is described in the Remarks for _IENavigate:

This function always returns a value of -1. This is because the navigate method has no useful return value and therefore nothing can be implied from it. You will need to employ other methods to determine success or failure of the navigation.

This is also true of the other functions you call out in the ticket.

You may not agree with my design choice, but I chose to have the functions always return -1 so that the user did not try to infer success or failure of the core function they were calling (like navigate, click or submit), regardless of the success or failure of the cascaded _IELoadWait . You can catch a problem with _IELoadWait by checking @error. I use -1 as a return value consistently in IE.au3 when there is an indeterminate return from a method call.

This is a day-one issue with the docs for these functions and they do need to be corrected to properly describe the behavior.

Thanks for drawing my attention to the ticket. I will update it.

Dale

Edited March 28, 2013 by DaleHohm

[BrewManNH]

But the functions return 0 for several conditions, they don't always return -1, which was my point.

If Not IsObj($o_object) Then
        __IEErrorNotify("Error", "__IENavigate", "$_IEStatus_InvalidDataType")
        Return SetError($_IEStatus_InvalidDataType, 1, 0) ; <<<<<<<<<<< Here it returns 0 when it encounters an error with the $o_object passed
    EndIf

Either it always needs to return -1 and tell the user to check @error, or correct the return for the _IELoadWait return value. The return values are inconsistent, and either the documentation needs correcting or the code does.

[DaleHohm]

Ah, yes, I see your point. Thank-you.

If it errors out before even attempting the method, I am setting the return value to 0 (since the success of the method is NOT indeterminate). If we get as far as attempting the method, I set the return value to -1 (because the success of the method is indeterminate) even if the cascaded _IELoadWait fails.

This is the way I choose to have it work, so I will insure that this is also included in the helpfile.

Dale

[DaleHohm]

So, back to the main reason I posted this...

I encourage people to try out this version with the beta - particularly those who have experienced "the WEND error" - and post any trouble you experience.

Dale

[tebennett]

DaleHohm,

Thank you for making these updates to IE.au3. After I found the "Beta Run" menu; the script I have written and use at work has been processing through all of the inventory updates without issue.

My words cannot express how happy I am with this update. Sometimes I could go a full 12 minutes before the WEnd error message appears. I am pleased to report it has been an hour! The entire time I have been writing and troubleshooting the script I would have sworn it was:

* the external website we use to keep our inventory

* the internet filter / firewall between us and the external website

By the way; thank you for all of your posts and contributions on the AutoIt forums, been reading them and making corrections to my scripts. The DebugBar was a god send.

Thank you again,

Thomas E. Bennett

Edited April 3, 2013 by tebennett

[DougShields]

Doh! I backed out from 3.3.8.1 to 3.3.6.1 a year ago due to an IE.au3 WEnd error on line 585 and finally got around to addressing it yesterday afternoon/this morning, just to find this thread an hour later. Timing is everything, as I really could have just kept waiting until the next release...

Anyway, my problems/fixes for 3.3.8.1 were :

• __IEIsObjType deregisters the internal error handler while _IELoadWait is depending on it so I added a reference counter to __IEInternalErrorHandlerRegister / __IEInternalErrorHandlerDeRegister.
• My underlying error ($IEComErrorScriptline = 585, $IEComErrorNumberHex = 80070005, $IEComErrorNumber = -2147024891, $IEComErrorWinDescription = Access is denied.) was treated as non-recoverable in __IEComErrorUnrecoverable, so I added a case to handle it as recoverable.

Reading the new version it looks like the new error handling and changes in __IEComErrorUnrecoverable effectively do the same things, so I expect it will work for me. I'll try actually testing the beta with my stuff to confirm (a 10000 line application control library that excercises IE/IE.au3 for ~45 minutes straight). If I really like the beta I might even put it on the Continuous Integration machine so we can get several runs every day until the next release comes out.

Underlying this... I cannot find any hint why $o_object.document.readyState is throwing the error rather than a meaningful state (like "uninitialized" perhaps). I can only confirm that $o_object.document is a valid HTMLDocument object, and that .readyState can go from valid to throwing this error to valid again in the span of a couple lines of AutoIT (i.e. breaking up line 574 into a $temp variable with 3 lines of code to build up the variable prior to WEnd, the code can fail on the .readyState=4 check even though the line before it succeeds on the .readyState="complete" check; with my changes and error notify turned on I can see the situation is usually recovered in 1 pass through the loop - i.e. ~100ms). Basically there is a very brief timing sensitive window where _IELoadWait can catch the HTMLDocument object with its pants down. In my case the app is basic form/submit stuff with postbacks and the occasional iFrame, so presumably IE is doing this while loading the new document into the window but I'm not going to deep dive IE's behaviour on this unless something else comes up.

Edited April 5, 2013 by DougShields

[DougShields]

Not a com/WEnd error, but I'll mention this one as well... There is an issue in IE.au3 in 3.3.6.1 that does not appear to be addressed in the new beta file - a WinWait("x") _IEAttach("x","dialogbox") pair can fail to attach because IE displays the dialog box window before it contains an IE control (probably very OS and IE version specific). It is timing sensitive as it requires AutoIT to execute a fair bit of code faster than IE can add the control to the window, but ultimately the "Local $h_control = ControlGetHandle()" line can miss getting the control because IE has not prepared the control on the window yet. In my experience the failure rate is less than 1 in 30 for my current environment. I have worked around this in my own code by inserting a check/sleep to delay _IEAttach if IE is not ready. Vastly simplified (let's assume relevant paramters and error checking exist in the real code):

WinWait($sMyWindow) ; Wait for the dialog box window
If ControlGetHandle($sMyWindow,[IE stuff]) = "" Then Sleep() ; Check if the window contains an IE control and delay if it is missing
$oIEDlg=_IEAttach($sMyWindow, "dialogbox")
_IELoadWait($oIEDlg)

Not sure how to fix that without supporting a timeout on _IEAttach, as there is no way to tell for certain how long to wait before retrying/giving up. Perhaps a small 100ms/10x retry loop getting the control would not offend anyone if the window looks like an IE window.

[coffeeturtle]

Thank you Dale Hohm for continuing to update this UDF!

If you get a chance, I was wondering if there was a way to harness the power of this UDF to create a script that will test an entire site (site collection) for any dead links?

I'm sorry in advance if this isn't the best place to post such a question, but I really could use an example script to build on. Some sites have scores of pages with an inestimable amount of links that should have been changed over the years. I wanted an in-house solution, if possible.

Thank you much!

[DaleHohm]

Nope, not the right place for this. Use the Support Forum. Note - this would not be an enhancement to IE.au3, but simply a project using IE.au3 and perhaps INetGet* or WINHTTP.

Dale

[coffeeturtle]

Thank you! I'm actually getting closer to a solution. But please know I don't think I could do this without your UDF!

[tuananh2701]

$oIE = _IECreate("http://www.website.com", 0, 0, 1)

C:\Program Files (x86)\AutoIt3\Include\ie.au3 (3690) : ==> The requested action with this object has failed.:

Local $oTemp = $o_object.document

Local $oTemp = $o_object.document^ ERROR

[DaleHohm]

Welcome to the forum, but hopefully your future posts are better ones.

First, you must know that you have not provided enough information for any type of analysis. You have left out all version information, omitted critical information written to the console and have provided no context for your code.

As well, I suspect that you are not running the version of AutoIt required to use this revised UDF since you seem to imply that your script aborts. The key to this revision is the 3.3.9 or higher version in which COM errors are no longer fatal.

If, after reviewing the above, you still have a problem, please open a topic in the Support forum.

Dale

[Iczer]

is there some method :

to get path to image in the browser cache

to make image show itself on the page (IE in OS configured to not to not show images by default)

[DaleHohm]

this is not the support forum.

[ivan]

File Name: IE.au3

File Submitter: DaleHohm

File Submitted: 27 Mar 2013

File Category: Libraries

Title: Internet Explorer Automation UDF Library for AutoIt3

Filename: IE.au3

Description: A collection of functions for creating, attaching to, reading from and manipulating Internet Explorer

Author: DaleHohm

Version: T3.0-0

Last Update: 9/3/12

Requirements: AutoIt3 3.3.9 or higher

This version is checked into the development stream for the next AutoIt beta release, but will work with the most recently released V3.3.9.x beta.

I am releasing it here so that it can get some testing now and help some people with some of the issues it fixes in the realm of COM error handling (and "the WEND error").

This file will be removed when it is included in a public beta release.

Dale

Thanks for posting this Dale.

I've got a couple of scripts that produce the wend error regularly, so I'll go ahead and test it out. I'll post the output should this occur.

Regards,

Ivan

[big_daddy]

Dale - I've run into the same issue twice now where changing a selection on a <Select> object does not fire the onchange event in IE9. It took some searching, but I found a related issue/solution in another language and ported it to AutoIt. I think this may be a good enhancement for IE.au3 to check the browser version and manually dispatch the event.

>First issue, >second issue, detailed bug report

I think the solution would be as easy as:

If $f_fireEvent Then
    If $o_object.document.documentMode = 9 Then
        $o_Evt = $o_object.document.createEvent("HTMLEvents")
        $o_Evt.initEvent("change", True, False)
        $o_object.dispatchEvent($o_Evt)
    Else
        $o_object.fireEvent("onChange")
        $o_object.fireEvent("OnClick")
    EndIf
EndIf

Edited July 8, 2013 by big_daddy

[lionfaggot]

I made 2 functions capable of solving most of anything you might ever need to do with IE, as showcased here: '?do=embed' frameborder='0' data-embedContent>>

it makes the process a lot less painful i daresay.