Sign in to follow this  
Followers 0
exodius

_IEAttach Issue Under 3.3.2.0

11 posts in this topic

#1 ·  Posted (edited)

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 by exodius

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

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 by PsaltyDS

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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


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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

Done and done. :evil:

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 by trancexx

♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 by PsaltyDS

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

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.


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

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.

;)


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

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?)


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

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.

;)


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0