_IEAttach Embedded multiple instances same window

[weaponx]

I'm trying to help kater in the generate Remote Assistance invitation file topic: http://www.autoitscript.com/forum/index.php?showtopic=51915

This will open Help and Support and retrieve the body text of the embedded IE control. Problem is there are about 4 instances and it's only grabbing the first. Any way to reference it like you can for Advanced Window Titles?

Something Like:

"[TITLE:Help and Support Center; INSTANCE:4]"

#include 
Run(@SystemDir & "\rcimlby.exe -LaunchRA")
WinWaitActive("Help and Support Center")
$OBJECT = _IEAttach ( "Help and Support Center", "Embedded")
$BODY = _IEBodyReadText ( $OBJECT )
MsgBox(0,"", "Body text: " & $BODY)

Note: Even if I click the Change View button in Help and Support, the first IE instance is still retrieved.

Edited August 24, 2007 by weaponx

[weaponx]

I tried modifying the IE UDF with little success.

IE.au3

I changed:

Line 313: $h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server1")

to

Line 313: $h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server4")

And I get this error:

IECustom.au3 (4012) : ==> The requested action with this object has failed.:

Return $oIE.document.parentwindow

Return $oIE.Document^ ERROR

[DaleHohm]

Are there 4 embedded instances in the same parent, or are there 4 windows with embedded IE instances?

If it is the leter, you should also be able to pass the hwnd of the parent window to _IEAttach instead of the title.

As you have figured out, the trick is to get ControlGetHandle to give you the handle of the correct embedded control. Play with that outside _IEAttach and figure out how to get it to work in the presented scenario and then see if you can pass an appropriate string to _IEAttach, thet will in turn feed ControlGetHandle.

Dale

[weaponx]

According to the window info tool there are 4 instances of Internet Explorer_Server within the Help and Support center window

[DaleHohm]

So what ControlGetHandle syntax allows you to connect to the one you want?

Dale

[weaponx]

This is the default code in IE.au3:

Line 313: $h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server1")

This is the only way it works.

If I change to:

Line 313: $h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server4")

The comments from the function make it seem like it can only work with instance 1

; Function Name: __IEControlGetObjFromHWND()

; Description: Returns a COM Object Window reference to an embebedded Webbrowser control

; Parameter(s): $hWin - HWND of a Internet Explorer_Server1 control obtained for example:

; $hwnd = ControlGetHandle("MyApp","","Internet Explorer_Server1")

; Requirement(s): Windows XP, Windows 2003 or higher.

; Windows 2000; Windows 98; Windows ME; Windows NT may install the

; Microsoft Active Accessibility 2.0 Redistributable:

; http://www.microsoft.com/downloads/details...;displaylang=en

; Return Value(s): On Success - Returns DOM Window object

; On Failure - 0 and sets @ERROR = 1

; Author(s): Larry with thanks to Valik

[DaleHohm]

As asked above, can you get ControlGetHandle to get the handle for the desired instance? If so, what string tdo you use? This question has nothing to do with _IEAttach or __IEControlGetObjFromHWND

You either need to test this and provide the answer or provide a simple way for me to test.

thanks,

Dale

[weaponx]

$h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server4") is successful no @ERROR

Then this line is called $oResult = __IEControlGetObjFromHWND($h_control)

I don't know how the $lResult var is getting set but it's the same regardless of what control I enter

$aRet = DllCall below is successful as well because an isObj is run against it successfully

Func __IEControlGetObjFromHWND(ByRef $hWin)
    DllCall("ole32.dll", "int", "CoInitialize", "ptr", 0)
    Local Const $WM_HTML_GETOBJECT = __IERegisterWindowMessage("WM_HTML_GETOBJECT")
    Local Const $SMTO_ABORTIFHUNG = 0x0002
    ;$lResult is declared but never set in this script ???
    Local $lResult, $typUUID, $aRet, $oIE
    
    __IESendMessageTimeout($hWin, $WM_HTML_GETOBJECT, 0, 0, $SMTO_ABORTIFHUNG, 1000, $lResult)
    
    $typUUID = DllStructCreate("int;short;short;byte[8]")
    DllStructSetData($typUUID, 1, 0x626FC520)
    DllStructSetData($typUUID, 2, 0xA41E)
    DllStructSetData($typUUID, 3, 0x11CF)
    DllStructSetData($typUUID, 4, 0xA7, 1)
    DllStructSetData($typUUID, 4, 0x31, 2)
    DllStructSetData($typUUID, 4, 0x0, 3)
    DllStructSetData($typUUID, 4, 0xA0, 4)
    DllStructSetData($typUUID, 4, 0xC9, 5)
    DllStructSetData($typUUID, 4, 0x8, 6)
    DllStructSetData($typUUID, 4, 0x26, 7)
    DllStructSetData($typUUID, 4, 0x37, 8)
    
    MsgBox(0,"",$lResult)
    $aRet = DllCall("oleacc.dll", "int", "ObjectFromLresult", "int", $lResult, "ptr", DllStructGetPtr($typUUID), "int", 0, "idispatch_ptr", "")
    
    If IsObj($aRet[4]) Then
        $oIE = $aRet[4].Script ()
        ; $oIE is now a valid IDispatch object
        Return $oIE.document.parentwindow ;FAILS HERE
    Else
        SetError(1)
        Return 0
    EndIf
EndFunc   ;==>__IEControlGetObjFromHWND

[weaponx]

I am convinced this is a limitation in __IEControlGetObjFromHWND in the IE UDF

More specifically __IESendMessageTimeout retrieves the same lResult no matter what $hcontrol is sent to it

I am thinking the function :

$aRet = DllCall("oleacc.dll", "int", "ObjectFromLresult", "int", $lResult, "ptr", DllStructGetPtr($typUUID), "int", 0, "idispatch_ptr", "")

Is returning the wrong object because the __IESendMessageTimeout onnly gets lResult from the first instance found

[DaleHohm]

After some testing, __IEControlGetObjFromHWND is in fact able to get the correct IE instance returned if you pass in the other control handles:

#include <IE.au3>
_IEErrorHandlerRegister()

ShellExecute("rcimlby.exe",  "-LaunchRA")
WinWaitActive("Help and Support Center", "")

$h_control = ControlGetHandle("Help and Support Center", "", "[CLASS:Internet Explorer_Server; INSTANCE:3]")
$oIE = __IEControlGetObjFromHWND($h_control)

ConsoleWrite(_IEDocReadHTML($oIE) & @CR)

That example works properly for instances 1 and 3. For instances 2 and 4 however, an "Access is Denied" COM error is triggered when trying to access the .document property of the resulting object (this is done in __IEControlGetObjFromHWND like this: $oIE.document.parentwindow). I have looked at these objects with a spy and I don't see what the key difference between 1/3 and 2/4 is - other than 2/4 contain frames and 1/3 do not and I see no reason for that to cause trouble.

So, there is an opportunity here to enhance _IEAttach (that would allow attaching to instances 1 and 3 in this case), but do not see a way around the Access Is Denied error with instances 2 and 4.

Dale

[weaponx]

I was trying something like this:

My Program:

expandcollapse popup

#include "IECustom.au3"
$title = "Help and Support Center"

If NOT WinExists ($title) Then
    Run(@SystemDir & "\rcimlby.exe -LaunchRA")
    WinWaitActive($title)
Else
    WinActivate ($title)
EndIf
$OBJECT = _IEAttach ($title, "Embedded", 4)

$BODY = _IEBodyReadText ( $OBJECT )
MsgBox(0,"", "Body text: " & $BODY)oÝ÷ Ù³(uøt»z'*ÞëÚßÛjëh×6Func _IEAttach($s_string, $s_mode = "Title", $instance = 1)
    $s_mode = StringLower($s_mode)
    Local $o_Shell = ObjCreate("Shell.Application")
    Local $o_ShellWindows = $o_Shell.Windows (); collection of all ShellWindows (IE and File Explorer)
    Local $h_control, $oResult, $f_isBrowser, $s_tmp
    
    ; Embedded browser controls and modal/modeless dialogboxes are not
    ; included in ShellWindow collection so handle them seperately
    If $s_mode = "embedded" Or $s_mode = "dialogbox" Then
        Local $iWinTitleMatchMode = Opt("WinTitleMatchMode")
        Opt("WinTitleMatchMode", 2)

        $h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server" & $instance)
        If @ERROR Then MsgBox(0,"","No matching control found")
        
        $oResult = __IEControlGetObjFromHWND($h_control)
        Opt("WinTitleMatchMode", $iWinTitleMatchMode)
        If IsObj($oResult) Then
            SetError($_IEStatus_Success)
            Return $oResult
        Else
            __IEErrorNotify("Warning", "_IEAttach", "$_IEStatus_NoMatch")
            SetError($_IEStatus_NoMatch, 1)
            Return 0
        EndIf
    EndIf

Heres where things get tricky for me. I have torn apart __IEControlGetObjFromHWND and still know little about it.

This line:

$RESULT = __IESendMessageTimeout($hWin, $WM_HTML_GETOBJECT, 0, 0, $SMTO_ABORTIFHUNG, 1000, $lResult)

Sets $lResult to 49246 when I pass it :

$h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server1")

or

$h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server4")

The limitation being that only the first instance of Internet Explorer_Server is being hit with the message.

Now since $lResult is always the same you would think this next dllcall would return the same object since thats the only independent variable:

$aRet = DllCall("oleacc.dll", "int", "ObjectFromLresult", "int", $lResult, "ptr", DllStructGetPtr($typUUID), "int", 0, "idispatch_ptr", "")

I really think $lResult should change when __IESendMessageTimeout is passed different handles.

Edited August 27, 2007 by weaponx

[DaleHohm]

Please execute my code above for instances 1, 2, 3 and 4 (change INSTANCE in the ControlGetHandle line). Hopefully you will see what I am talking about.

Dale

[weaponx]

I get the same handle and error if I use:

$instance = 4

$h_control = ControlGetHandle($s_string, "", "Internet Explorer_Server" & $instance)

or

$h_control = ControlGetHandle("Help and Support Center", "", "[CLASS:Internet Explorer_Server; INSTANCE:4]")

IECustom.au3 (4039) : ==> The requested action with this object has failed.:

Return $oIE.document.parentwindow

Return $oIE.Document^ ERROR

[DaleHohm]

You obviously are not running the example code I posted above.

That code simplifies the scenario significantly over your analysis. It demonstrates that __IEControlGetObjFromHWND is working properly, contrary to your conclusions.

There is an additional complication with instances 2 and 4 that result in an Access Is Denied COM error (which you will not see without _IEErrorHandlerRegister() or equilalent trapping). IE appears to be treating it as a cross-frame security restriction due to some characteristic of the content loaded there.

As noted above, _IEAttach does currently limit attachment to the first embedded control and I will address this as an enhancement in a future release. The workaround of calling __IEControlGetObjFromHWND directly in my example above can be used in the mean time.

Dale

Edited August 27, 2007 by DaleHohm

[weaponx]

I never tested it with instance 3 just because the window info tool didn't pick it up (since it's straight code)

I do see the COM errors on instance 4 though:

--> COM Error Encountered in New AutoIt v3 Script.au3

----> $IEComErrorScriptline = 4039 (Return $oIE.document.parentwindow)

----> $IEComErrorNumberHex = 80020009

----> $IEComErrorNumber = -2147352567

----> $IEComErrorWinDescription = Access is denied.

----> $IEComErrorDescription = Access is denied.

----> $IEComErrorSource =

----> $IEComErrorHelpFile = C:\WINDOWS\system32\mshtml.hlp

----> $IEComErrorHelpContext = 0

----> $IEComErrorLastDllError = 0

--> IE.au3 Error from function _IEDocReadHTML, $_IEStatus_InvalidDataType

0

--> IE.au3 Warning from function _IEAttach, $_IEStatus_NoMatch

--> IE.au3 Error from function _IEBodyReadText, $_IEStatus_InvalidDataType

So it's almost as if this control is locked somehow?

Whats strange to me is that

If IsObj($aRet[4]) Then

is successful, so some kind of object is being returned from the oleacc.dll, I wonder what kind of object it is.

Edited August 27, 2007 by weaponx

[DaleHohm]

It is a DispHTMLWindow2 object just as you would expect. you can actually do a .navigate on that $aRet[4] object, to www.google.com for example, and you'll get a google in that bottom right quadrant.

There is a security restriction in IE that is preventing you from diving into the DOM in that instance. Again, it would appear that IE is seeing the access as a cross-frame security violation, whis is typically when that Access Is Denied error is generated.

Dale

[weaponx]

I see what you mean. I did this:

$oIE = $aRet[4].Script ().navigate("http://www.google.com")

So if $aRet[4].Script () is the IHTMLWindow2 Interface I assume most or all of these functions are available:

http://msdn2.microsoft.com/en-us/library/aa741505.aspx

Can any functions be called on the root $aRet[4] object other than Script() ????

[DaleHohm]

Most result in Access Is Denied -- I tried.

Dale

[DaleHohm]

The documents loaded in the Help and Support center use a special protocol (hcp://) registered specifically for its use. There have been some security vulnerabilities discovered with hcp:// in the past and I am guessing that they have therefore flipped the "paranoid bit" -- likely explaining the Access Is Denied errors. I cannot find anything documented on this and do not expect a workaround, but would be glad to be proven wrong.

Dale

[weaponx]

Even after you use the navigate() function to go to google, the html still cannot be read. There must be some kind of lock on the control itself.