Release 3.3.14.0 IE.au3 throws an error

[Martineau]

Windows 8.1

IE 11.0.9600.17842
Update Versions: 11.0.20

Just updated to release 3.3.14.0 and IE.au3 throws an error?

 

expandcollapse popup

Func MatchWebPageTAB($sMatchType, $sMatchString, $sBodyString, $Timeout = 0, $bDumpToFileBody = False, $bDebug = False)


 Local $bIE_error = _IEErrorNotify()   ; Save the status of IEErrorNotify()
 _IEErrorNotify(False)      ; ....temporarily turn it OFF

 Local $bMatch = False
 Local $oThisOBj = 0
 Local $iINDEXMatch = 0
 Local $IE = 0

 Dim $aIE[1][6]  ; Array to hold details about Page/TAB object
 Local $i = 1

 $aIE[0][0] = 0  ; Count of matching objects....

 Local $bABBREV = False
 Local $bABBREVSTAR = False

 ; Examine ALL open web pages/TABS
 While 1

  $IE = _IEAttach(Default, "instance", $i)
  If @error = $_IEStatus_NoMatch Then ExitLoop

  if $bDebug Then
     ConsoleWrite(">" & "Web page: Title='" & _IEPropertyGet($IE, "title") & "'" & @CRLF & "           URL='" & _IEPropertyGet($IE, "locationurl") & "'" & @CRLF)
     EndIf



  ReDim $aIE[$i + 1][6]

  $aIE[$i][0] = $IE
  if not isobj($IE) then ConsoleWrite("!" & "$IE is not an object!" & @CRLF)

  $aIE[$i][1] = _IEPropertyGet($IE, "title")
  ConsoleWrite("+" & "$IE title='" & $aIE[$i][1] & "'" & @CRLF)
  $aIE[$i][2] = _IEPropertyGet($IE, "locationurl")  ; Save the full URL however complex!!!
  ConsoleWrite("+" & "$IE url='" & $aIE[$i][2] & "'" & @CRLF)
  $aIE[$i][3] = _IEPropertyGet($IE, "hwnd")
  ConsoleWrite("+" & "$IE hwd='" & $aIE[$i][3] & "'" & @CRLF)
  $aIE[$i][4] = _IEPropertyGet($IE, "uniqueid")
  ConsoleWrite("+" & "$IE uniqueid='" & $aIE[$i][4] & "'" & @CRLF)

  $aIE[0][0] = $i   ; Count of Pages/Tabs

        ;<snip>
  
 Wend
 
Endfunc

 

 

 

SciTE output

>"C:\Program Files (x86)\AutoIt3\SciTE\..\AutoIt3.exe" /ErrorStdOut "C:\$Data\Windows scripting\Autoit\SNBLogin.au3"   
+$IE title='SmallNetBuilder Forums'
+$IE url='http://www.snbforums.com/'
+$IE hwd='0x01CB0214'
"C:\Program Files (x86)\AutoIt3\Include\IE.au3" (2327) : ==> The requested action with this object has failed.:
Return SetError($_IESTATUS_Success, 0, $oObject.uniqueID)
Return SetError($_IESTATUS_Success, 0, $oObject^ ERROR

[guinness]

You need to implement your own COM error handler, as AutoIt doesn't "hide" errors anymore.

[Martineau]

You need to implement your own COM error handler, as AutoIt doesn't "hide" errors anymore.

Really?....

With all due respect this is the most ridiculous response ever! "Autoit doesn't hide errors anymore"  ...Hmm so what errors was Autoit keeping to itself under 3.3.12.0 and earlier?

I have endeavoured to report that if I issue a simple statement such as this

_IEPropertyGet($IE, "uniqueid")

under 3.3.14.0 I now have no way of checking the @‌error status from this function? given the IE.au3 function never returns: 

Success:	the selected property.
Failure:	0 and sets the @error flag to non-zero.
@error:	3 ($_IEStatus_InvalidDataType) - Invalid Data Type 4 ($_IEStatus_InvalidObjectType) - Invalid Object Type 5 ($_IEStatus_InvalidValue) - Invalid Value
@extended:	Contains invalid parameter number

Are you saying that my invocation of what should be a perfectly legitimate syntactically and functionally single line of code is invalid? - if so why?

So guiness whilst bowing to your apparent considerable knowledge compared to my limited Autoit coding skills, explain exactly, nay provide the COM handler to show precisely how a COM handler will help to correct my program.

 

Edited July 11, 2015 by Martineau

[mLipok]

read here:

https://www.autoitscript.com/autoit3/docs/intro/ComRef.htm

and here:

https://www.autoitscript.com/autoit3/docs/functions/ObjEvent.htm

 

[Melba23]

Martineau,

so what errors was Autoit keeping to itself under 3.3.12.0 and earlier?

One good example: _ArrayUnique was failing silently when used with Int64 values - this only came to light when COM errors became fatal. If you want to see an example of how you need to code with your own error handler, look at that function in the Array library together with the _ArrayUnique_AutoErrRegister, __ArrayUnique_AutoErrUnregister & __ArrayUnique_AutoErrFunc functions which show the handler being used.

As to why it changed, I quote Jon:

I'm pretty sure I'm going to leave the COM errors as fatal without a handler as they were in 3.3.8.1.  I think it's a bit unreasonable for someone using COM to not know if they've made a simple typo because everything is being silently handled. It's easy enough to add a handler when required but it doesn't seem right that a user _must_ install a handler to be sure that they've not just typed something wrong...

I hope that satisfies your (rather arrogantly expressed) demand to:

explain exactly, nay provide the COM handler to show precisely how a COM handler will help to correct my program

You might want to keep a more civil tone in future posts.

M23 

[Martineau]

Martineau,

One good example: _ArrayUnique was failing silently when used with Int64 values - this only came to light when COM errors became fatal. If you want to see an example of how you need to code with your own error handler, look at that function in the Array library together with the _ArrayUnique_AutoErrRegister, __ArrayUnique_AutoErrUnregister & __ArrayUnique_AutoErrFunc functions which show the handler being used.

As to why it changed, I quote Jon:

I hope that satisfies your (rather arrogantly expressed) demand to:

You might want to keep a more civil tone in future posts.

M23 

 

I apologise if my tone seemed rude, but I simply tried to report that working code suddenly falls in a heap under 3.3.14.0, and I basically received an answer along the lines "it's your coding that is the problem"

 

Furthermore I didn't write the _IEPropertyGet() function and I have clearly for many years correctly called the function without logic or syntax errors.

So If I look in the comprehensive help  - as so very often noob posters are arrogantly told to basically RTFM, precisely where exactly does it say that in order to use _IEPropertyGet() you will need to include a COM handler?

 

So quite simply,  is _IEPropertyGet()  under 3.3.14.0 broken ? Answer YES or NO ...or is this too terse a question?

Edited July 11, 2015 by Martineau

[JohnOne]

No, it is not broken.

[Martineau]

No, it is not broken.

So why does it report this?

"C:\Program Files (x86)\AutoIt3\Include\IE.au3" (2327) : ==> The requested action with this object has failed.:
Return SetError($_IESTATUS_Success, 0, $oObject.uniqueID)
Return SetError($_IESTATUS_Success, 0, $oObject^ ERROR

[mLipok]

Upon reflection, I wonder why that information

You need to implement your own COM error handler, as AutoIt doesn't "hide" errors anymore.

was not included in this document: "Script Breaking Changes"

EDIT: or I miss something ???

ps.
I wonder though this information was already known to me (since I followed the changes in BETA version).

Edited July 11, 2015 by mLipok

[trancexx]

@‌Martineau, you are completely right about this thing. Your code is broken with the new release. Unfortunately you can't do anything about it but try to adjust.
The change was made by someone who doesn't fully understand internal working and the idea behind the Automation and COM in general. Dispatch interface in it's essence, was made up to avoid unexpected terminations and situations you face here. Any attempt of users to point to the mistake made in recent development of AutoIt where shut down, and users were hounded, like they are some enemies of AutoIt.
Probably every user that used objects in AutoIt share your thoughts, and few of them have said almost the same thing as you. All ignored, some punished.

Start COM error handler before you use COM in AutoIt, and you will be fine. Look for ObjEvent function.

[JohnOne]

The reason I say it's not broken is because I used it after poster asked is it was broken requesting a binary answer, and it worked just fine.

So the way I see it, the poster's code is broken because of a documented script breaking change, but the function is not.

[mikell]

Does all this mean that _IEErrorHandlerRegister() - "Register and enable a user COM error handler" - would be back soon ?
 

[guinness]

 

I basically received an answer along the lines "it's your coding that is the problem"

I never said that in my post. I explained how to fix it and why it was causing the error. There was no "attitude" in my post!

[evoportals]

I just wanted to chime in here.

YES... the new version of Autoitit has broken the IE.au3 library. EACH function in IE.au3 must now be manually rewritten with a COM error handle. You can't handle the COM errors in your script unfortunately as the functions reside in IE.au3. Yes it is a total mess now and I have been speaking out about this and warning people to AVOID IE.au3 library at all costs. It is not a viable library to use with Autoit anymore.

If you need to automate IE and don't want to rewrite your required IE.au3 functions then I would recommend a different programming language like Python since the IE libraries are stable and correctly coded.

[mLipok]

I just wanted to chime in here.

YES... the new version of Autoitit has broken the IE.au3 library. EACH function in IE.au3 must now be manually rewritten with a COM error handle. You can't handle the COM errors in your script unfortunately as the functions reside in IE.au3. Yes it is a total mess now and I have been speaking out about this and warning people to AVOID IE.au3 library at all costs. It is not a viable library to use with Autoit anymore.

If you need to automate IE and don't want to rewrite your required IE.au3 functions then I would recommend a different programming language like Python since the IE libraries are stable and correctly coded.

did you read this:

    ie.au3 UDF with AutoIt v3.3.14.x  

???

mLipok

 

[mLipok]

About Python issues with IE you can read for example here:

https://github.com/enthought/comtypes/issues/66

 

and btw.

actually ie.au3 is in work in progress stage (I mean I work on it, and you should wait for finall results).

Edited October 15, 2015 by mLipok