_IEAttach Issue Under 3.3.2.0

[exodius]

I've noticed this issue with using _IEAttach to attach to an embedded window since I upgraded from 3.3.0.0 to 3.3.2.0:

The first time I run _IEAttach it works correctly, but any subsequent time I try to use it in the same script without killing it and reopening it, it fails. (Like if the window I want to attach to gets closed and reopened, or even if I try to just run it a second time to attach a 2nd variable to a 2nd window)

I'm able to reproduce this issue, when I downgrade to 3.3.0.0 the following works perfectly, when I upgrade back to 3.3.2.0 the issue comes back.

Run this first

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <IE.au3>

_IEErrorHandlerRegister ()

$oIE = _IECreateEmbedded ()
GUICreate("Embedded Web control Test", 640, 580)
$GUIActiveX = GUICtrlCreateObj($oIE, 10, 40, 600, 360)
GUISetState()
_IENavigate ($oIE, "http://www.google.com")

While 1
    $msg = GUIGetMsg()
    Select
        Case $msg = $GUI_EVENT_CLOSE
            ExitLoop
    EndSelect
WEnd

GUIDelete()
Exit

Run this 2nd

#include <IE.au3>

$oIE = _IEAttach("Embedded Web control Test", "embedded")
MsgBox (0, "", _IEDocReadHTML($oIE))

$oIE = _IEAttach("Embedded Web control Test", "embedded")
MsgBox (0, "", _IEDocReadHTML($oIE))

Does anyone else have this same issue? I'm running Windows XP SP3 32 bit and IE7.

**Edit: In the interest of being thorough, this is what I get back from IE.au3 V2.4-0 for an error message when the script hits the 2nd _IEAttach under 3.3.2.0:

--> IE.au3 V2.4-0 Warning from function _IEAttach, $_IEStatus_NoMatch
--> IE.au3 V2.4-0 Error from function _IEDocReadHTML, $_IEStatus_InvalidDataType

Under 3.3.0.0 I get the html of google.com twice.

Edited December 31, 2009 by exodius

[PsaltyDS]

Interesting. The _IEAttach() function calls __IEControlGetObjFromHWND() internally, which doesn't recognize the return value of the DllCall:

Func __IEControlGetObjFromHWND(ByRef $hWin)
    Local $aRet = DllCall("ole32.dll", "long", "CoInitialize", "ptr", 0)
    If @error Then Return SetError(2, @error, 0)
    If $aRet[0] <> 0 Then Return SetError(4, $aRet[0], 0)
    
    ; ...

It returns @error = 4. Commenting out the line that checks $aRet[0] made it work normally. I suspect there are some non-zero but normal return values not covered by that error checking.

By the way, there is no need for two scripts to demo the error. I got it solidly this way:

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <IE.au3>

_IEErrorHandlerRegister()

$oIE = _IECreateEmbedded()
$hGUI = GUICreate("Embedded Web control Test", 640, 580)
$GUIActiveX = GUICtrlCreateObj($oIE, 10, 40, 600, 360)
GUISetState()
_IENavigate($oIE, "http://www.google.com")


$oIE2 = _IEAttach($hGUI, "embedded")
MsgBox(0, "Err = " & @error, _IEDocReadHTML($oIE2))

$oIE3 = _IEAttach($hGUI, "embedded")
MsgBox(0, "Err = " & @error, _IEDocReadHTML($oIE3))

While 1
    $msg = GUIGetMsg()
    Select
        Case $msg = $GUI_EVENT_CLOSE
            ExitLoop
    EndSelect
WEnd

GUIDelete()
Exit

Edited January 4, 2010 by PsaltyDS

[exodius]

So should I open a bug ticket for this, or would it be safe to assume that someone (and by someone I mean Dale) is looking into it?

[DaleHohm]

I am looking at it along with the analysis that PsaltyDS did... particularly since it appears taht a change to DllCall is involved as well it would still be best for you to create a ticket to insure this is tracked.

Dale

[exodius]

I am looking at it along with the analysis that PsaltyDS did... particularly since it appears taht a change to DllCall is involved as well it would still be best for you to create a ticket to insure this is tracked.

Dale

Done and done.

http://www.autoitscript.com/trac/autoit/ticket/1389

[trancexx]

Done and done.

http://www.autoitscript.com/trac/autoit/ticket/1389

No. That's wrong.

There is nothing wrong with anything except with error handling with that function. <-that's many withs

I said already that this function is not optimized, but seems I was ignored (yes again ).

S_FALSE is the answer. (over-scripting)

Edited January 4, 2010 by trancexx

[PsaltyDS]

There is nothing wrong with anything except with error handling with that function.

S_FALSE is the answer. (over-scripting)

That's what I meant by: "I suspect there are some non-zero but normal return values not covered by that error checking." The MSDN for the coInitialize function lists several possible return values, more than one are normal and not an error, like S_FALSE. I assume S_OK = 0, but S_FALSE = 1 is also a normal return if coInitialize was previously done for the thread. If it's not from a change Dale made in IE.au3, then maybe something in AutoIt is now doing coInitialize in the thread before the IE function gets called.

Edited January 4, 2010 by PsaltyDS

[trancexx]

That's what I meant by: "I suspect there are some non-zero but normal return values not covered by that error checking." The MSDN for the coInitialize function lists several possible return values, more than one are normal and not an error, like S_FALSE. I assume S_OK = 0, but S_FALSE is also a normal return if coInitialize was previously done for the thread. If it's not from a change Dale made in IE.au3, then maybe something in AutoIt is now doing coInitialize in the thread before the IE function gets called.

Yes, of course. That's why I picked exodius's post to quote in my reply and not yours.

Your debugging capabilities are well known.

[PsaltyDS]

Yes, of course. That's why I picked exodius's post to quote in my reply and not yours.

Your debugging capabilities are well known.

Actually, I googled that stuff up when I first looked at this topic. I don't have enough experience with DLL calls and the WinAPI to know if I put it together correctly. You could further my education if you could tell me why it's necessary to "identif(y) the concurrency model as single-thread apartment" (the purpose of coInitialize) for this function in the first place. That's still a little over my head.

[trancexx]

Actually, I googled that stuff up when I first looked at this topic. I don't have enough experience with DLL calls and the WinAPI to know if I put it together correctly. You could further my education if you could tell me why it's necessary to "identif(y) the concurrency model as single-thread apartment" (the purpose of coInitialize) for this function in the first place. That's still a little over my head.

Because ObjectFromLresult function would fail and return 0x800401F0 (CO_E_NOTINITIALIZED) otherwise.

(Too pragmatic?)

[PsaltyDS]

Because ObjectFromLresult function would fail and return 0x800401F0 (CO_E_NOTINITIALIZED) otherwise.

(Too pragmatic?)

Ah, so.

I didn't get that from the article for the ObjectFromLresult function. I also missed how singular this call is (only once in IE.au3 and only used when _IEAttach() and "embedded" is used). Mistakenly thought there must be some more general requirement to do that. Thanks for the tip.