I.E.au3 slow response problem

[Bert]

Ok, this has me stumped. I have a viewer that when I use it for any website, works great. If I try to use it for USD (Unicenter ServiceDesk, Web based) the embedded IE window is very slow. To open up a ticket, takes 10 seconds. Now here is the odd part. If I just use IE, it runs fine. No slowdowns. Unless someone has USD at their work, it would be hard to test it. The only thing I can think to test it is a website that opens a child window. For the life of me, I ca't think of a site that does this. Anyone know of one I can use to test it?

I don't mean a popup ad, I mean a child window of the site, such as for example a banking site opening a child window to display information.

I'm using this to test:

expandcollapse popup

#include <GUIConstants.au3>
#include <IE.au3>

_IEErrorHandlerRegister ()

$oIE = _IECreateEmbedded ()
GUICreate("Embedded Web control Test", 640, 580, _
        (@DesktopWidth - 640) / 2, (@DesktopHeight - 580) / 2, _
        $WS_OVERLAPPEDWINDOW + $WS_VISIBLE + $WS_CLIPSIBLINGS)
$GUIActiveX = GUICtrlCreateObj($oIE, 10, 40, 620, 480)
$GUI_Button_Back = GUICtrlCreateButton("Back", 10, 540, 100, 30)
$GUI_Button_Forward = GUICtrlCreateButton("Forward", 120, 540, 100, 30)
$GUI_Button_Home = GUICtrlCreateButton("Home", 230, 540, 100, 30)
$GUI_Button_Stop = GUICtrlCreateButton("Stop", 340, 540, 100, 30)
GUICtrlSetResizing($GUIActiveX, $GUI_DOCKBORDERS)
GUICtrlSetResizing($GUI_Button_Back, 8)
GUICtrlSetResizing($GUI_Button_Forward,8)
GUICtrlSetResizing($GUI_Button_Home, 8)
GUICtrlSetResizing($GUI_Button_Stop, 8)
GUISetState()       ;Show GUI

_IENavigate ($oIE, "http://www.autoitscript.com")

; Waiting for user to close the window
While 1
    $msg = GUIGetMsg()
    Select
        Case $msg = $GUI_EVENT_CLOSE
            ExitLoop
        Case $msg = $GUI_Button_Home
            _IENavigate ($oIE, "http://www.autoitscript.com")
        Case $msg = $GUI_Button_Back
            _IEAction ($oIE, "back")
        Case $msg = $GUI_Button_Forward
            _IEAction ($oIE, "forward")
        Case $msg = $GUI_Button_Stop
            _IEAction ($oIE, "stop")
    EndSelect
WEnd

GUIDelete()

Exit

Edited October 11, 2007 by Volly

[Bert]

I tried using http://www.popuptest.com/, but it seems to work fin there....anyone know a site to test?

[Bert]

I'm beginning tho think the issue lies here:

For the gui, the window class is AutoIt v3 GUI, but for a regular IE window, the window class is IEFrame. I think Unicenter doesn't like this, and is causing my slowdown. Is there a different method to attach a IE window to a GUI that is stable? Lod3n had a duel method, but it is very unstable in my enviroment.

[lod3n]

There's no way that a website can read the window class.

But I do have an idea. This is just a shot in the dark, but I think the problem has to do with the User Agent string that the embedded IE control is sending to the page. Take a look here:

#341642

When embedded, using the standard _Navigate method from IE.au3, the user agent is sent as "AutoIt v3". They might be thinking it's smart to look at that string, find that "MSIE" doesn't exist in it, and be assuming it's Firefox or Safari or something. So try this:

;_IENavigate ($oIE, "http://www.autoitscript.com")

$agentString = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;)"

__IENavigate ($oIE, "http://www.autoitscript.com", 1, 0, "", "", "User-Agent: "& $agentString & @CRLF)

; ^ note the double underscores on this version

[Bert]

Nice...I'll try this when I get to the office tomorrow. I tell you, I've tried several different approaches with this viewer, and I keep running into walls. If this works like I think it will, WOOHOO!

Thanks for the tip!

[Bert]

Trid what you suggested, and it doesn't fix the slowdown. The user agent is showing up as this:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; STIE60-021004; STIE60-020212; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1)

It makes no difference if I use method 1 or 2.

I'v been playing around with it all morning, and I'm no closer to what is causing the slowdown. Is there anything else I can check or things to read that may give me some direction? What you gave me so far was quite interesting, and I learned some good stuff. I also tried the HTTP.au3, and had no luck there either. This one is quite puzzling.

[DaleHohm]

Does it take a long time to display _anything_ or a long time to complete?

Dale

[Bert]

The parent window will load fine, no speed loss. The problem occures when I try to open a child window. In USD while looking at the main window, there is a menu. From the menu, go file > new incident. This will open a child window to allow for the incident to be created. In normal IE, this happens around 3 seconds to fully open the child. If I run USD from a embedded IE (using the code example I provided) , It takes 15 seconds for the child window to be fully opened. I have tried various websites that create child windows, but for the most part they simply tell a window to open, they don't interact with the child once opened. I believe the issue is with the 2 windows exchanging information.

[Bert]

Here are a couple of screen shots of what is happening:

Parent window -

Child window

[lod3n]

How about this: can you determine the URL that the Create New Incident child window is opening up in, and make a new button in your GUI that navigates the main IE control there? That would prevent the child window entirely. Then another button to navigate back to the main URL.

[Bert]

There would be 60 buttons, at least, and I would have to teach about 200 users what to do. I did notice when I used your duel IE setup I didn't have this problem, but I did have other issues:

• The only way to pull the entire GUI into focus was to click on the GUI frame. If I clicked on the attached IE pane, it would not gain focus.
• Novell's single signon DLL would crash
• IE would also crash
• The alt key would get stuck

I'm sure it is a simple matter of the fact it is embedded in the GUI is what is causing this. When using the AutoIt Info tool, it sees the main window in the viewer as a IE window control. Is there a method to have the script monitored as far as HTTP traffic it generated? I'm thinking I need to see what happens when I try to make a child window while running the script. I may be able to get a handle on what is happening.

[lod3n]

You can monitor IE HTTP traffic with Microsoft's Fiddler:

http://www.fiddlertool.com/fiddler/version.asp

It works as a local proxy, so it can capture everything, and is really great for this sort of thing.

[Bert]

Ok, I ran several test with the tool (by the way, Nice find!) It is capturing what the server is sending down, but not what is being asked by the parent window. (as far as I can tell. )

I did notice in the helpfile this little snippit-

; We choose for a specific Internet Explorer interface 'DWebBrowserEvents' because the IE is subject

; to modifications by e.g. Visual Studio and Adobe Acrobat Reader. If you have IE-plugins installed,

; AutoIt might not be able to find the correct interface automatically.

I wonder if this may have something to do with it.

[DaleHohm]

Perhaps a little isolation... try wrapping your desired site in an iFrame

Dale

p.s. I use Fiddler, but DebugBar also shows HTTP traffic

[lod3n]

It is capturing what the server is sending down, but not what is being asked by the parent window.

First, are you sure they are communicating at all? Does the parent window appear to react to the actions of the child window in some way?

If so, what that tells me is that the child window might be communicating via a Javascript object, probably window.parent, or top.window or something like that. It may be looking at frame names, or the window.title to determine things.

You're going to need to dig through the Javascript in the parent window that opens the child window, and find out what it's actually doing. DebugBar can help you do this (as well as watch HTTP traffic - BTW, thanks Dale, I've been using that for a few months now, it's not Firebug, but it's a lot better than many alternatives).

Really the best thing you can do is take the Javascript in question, and make a very simple version using similar code that demonstrates the problem. If you can replicate the problem, we would have a much better chance of cracking it.

[lod3n]

Also, do you have Javascript errors turned on in IE? Uncheck Disable Script Debugging in IE and Other under Tools/Internet Options/Advanced tab. If there's any errors at all you need to know about them.

[Bert]

Also, do you have Javascript errors turned on in IE? Uncheck Disable Script Debugging in IE and Other under Tools/Internet Options/Advanced tab. If there's any errors at all you need to know about them.

That is a hell of a good idea. I can try that one on monday

[Bert]

Ok, I tried to take a different approach to the problem. This approach fixes my speed problem, but now I have a new problem with resizing and the IE window being stable. It seems if I try to use IECreateEmbedded I get the speed problem, but this way I get a unstable window. I can resize it, but it is very unstable. Sometimes with resizing the IE pane will dissapear. Other times just something changing in the IE window will cause part of the window to be hidden. I suspect the issue is with GuiCtrlCreateLabel not refreshing right. This is one hard nut to crack.

expandcollapse popup

#cs ----------------------------------------------------------------------------

 AutoIt Version: 3.2.9.2 (beta)
 Author:         myName

 Script Function:
    Template AutoIt script.

#ce ----------------------------------------------------------------------------

; Script Start - Add your code below here
#region
#include <guiconstants.au3>
#include <ie.au3>
;~ #include <IET2.0.6.au3>
#include <misc.au3>

HotKeySet("{ESC}", "_Exit")

$gui = GUICreate("", 930, 800,-1,-1, $WS_OVERLAPPEDWINDOW + $WS_VISIBLE + $WS_CLIPSIBLINGS)
$Label_1 = GuiCtrlCreateLabel("", 10, 10, 900, 720)
_IEErrorHandlerRegister()

;setup ie win (2x)
    $oIE1 = _IECreate("about:blank",0,0,1,0)
    $oIE1.AddressBar = 0
    $oIE1.MenuBar = 0
    $oIE1.StatusBar = 0
    $oIE1.ToolBar = 0
    $uID1 = Random(1000, 100000000)
    $oIE1.document.title = $uID1
    WinWait($uID1, "", 7)
    $hoIE1 = WinGetHandle($uID1)
    $pid1 = WinGetProcess($hoIE1)
    
;embed
    DllCall("user32.dll", "long", "SetWindowLong", "hwnd", $hoIE1, "int", -16, "long", $WS_POPUP)
    DllCall("user32.dll", "int", "SetParent", "hwnd", $hoIE1, "hwnd", $gui)
    DllCall("user32.dll", "long", "SetWindowLong", "hwnd", $hoIE1, "int", -16, "long", $WS_CHILD)

;move
    $pos = ControlGetPos($gui, "", $Label_1)
    WinMove($hoIE1, "", $pos[0], $pos[1], $pos[2], $pos[3])
;nav
    ;_IENavigate ($oIE1, "http://usdp/CAisd/pdmweb.exe",1)
    _IENavigate($oIE1, "http://www.google.com/", 0)
;show   
    GuiSetState()
    
    $oIE1.visible=1
#endregion

WinActivate($gui)

While 1
    $msg = GUIGetMsg()
    Switch $msg
        Case $GUI_EVENT_CLOSE
            _IENavigate($oIE1, "about:blank")
            sleep(100);add stability for SSO
            Exit
        Case sizeEvent($msg)
            repositionIE()  
    EndSwitch
WEnd
_Exit()

Func _Exit()
    While ProcessExists($pid1) 
        ProcessClose($pid1)
    WEnd
    Exit
EndFunc
Func dbg($msg)
    ConsoleWrite($msg & @CRLF)
    DllCall("kernel32.dll", "none", "OutputDebugString", "str", $msg)
EndFunc
Func repositionIE()
    $pos1 = ControlGetPos($gui, "", "Static1")
    WinMove($hoIE1, "", $pos1[0], $pos1[1], $pos1[2], $pos1[3])
EndFunc   ;==>repositionIE
Func sizeEvent($event)
    If $event = $GUI_EVENT_MAXIMIZE Or _
            $event = $GUI_EVENT_MINIMIZE Or _
            $event = $GUI_EVENT_RESTORE Or _
            $event = $GUI_EVENT_RESIZED Then
        Return True
    Else
        Return False
    EndIf
EndFunc   ;==>sizeEvent

[Bert]

bump

[lod3n]

Embedding ActiveX controls (or other applications via SetParent) in your GUI can be a problematic experience. I solved a really tricky problem embedding an RDP window in one of my Example Scripts. You had to set a very specific set of styles on the main gui and the control before it performed correctly. Take a look, maybe there's something here that can help you:

http://www.autoitscript.com/forum/index.php?showtopic=39083