Performance issues with IE.au3 and ObjEvent

[RickyD]

I'm trying to automate some web forms using IE 6.0, and am running into a performance problem. I've searched the forums without success, so here I am.

Basically the issue is that if a button on the web form brings up another IE window, an incredible delay is seen when communicating with IE. I've attached a test program along with a short html file that illustrates the issue. I'm using AutoIt 3.3.4.0

To duplicate:

1) Bring up the "launchTest.html" file in IE (you may have to approve some blocked content)

2) Start the "launchTest.au3" script

3) Click on the "Restart Connection" button as many times as you'd like (on my system, the operation takes ~240 ms).

4) Now click on the button in the IE form. Google's home page should be displayed

5) Click on the "Restart Connection" button again. On my system, the operations now take ~3200 ms!

Additional observations:

1) If I comment out the ObjEvent() call (line 46 of the script), the problem goes away.

2) If I exit the script and restart it, the problem goes away (until another window is launched).

3) When the problem is happening, all of the other _IE calls (_IEGetObjById() for example) that I've tested also take a long time to return. However, the data returned is valid.

4) It doesn't make any difference if I have event functions defined or not. However, when the problem is happening, I don't seem to be receiving any event callbacks.

I've searched by every keyword I can think of to see if I'm doing something fundamentally wrong with ObjEvent, but I didn't find anything. Any help will be greatly appreciated.

Rick

launchTest.html

launchTest.au3

Edited February 9, 2010 by RickyD

[Steveiwonder]

I justed changed this line and it reduced the time.

$o_sink = ObjEvent( $o_IE, "IEEvent_", "DWebBrowserEvents")

No idea if it will break the rest of your project but worked for me.

Something to do with DWebBrowserEvents2? I'm not experience with obj yet but i'm guessing it's something there...

[DaleHohm]

Suggest you do some further timing tests to see which specific command(s) are actually consuming the time. Is there a reason that you need to destroy and recreate the event sink each time the button is clicked?

Dale

[RickyD]

What I posted was just a very small test program I threw together that depicts the problem. In my actual application, I only deregister the event handler if the user navigates away from the web form that I want to "watch". Since it seemed that the ObjEvent call was somehow the culprit, I simplified my test program to the bare minimum. The _IEAttach() is always very fast (~10 ms). Even when I keep the original event registration, other calls, such as _IEGetObjById() exhibit the same issue. I've attached another version of my test program that breaks down the times better.

What really gets me is that this only seems to be an issue if AutoIt has registered for events before the new window is brought up. (This can be seen by bringing up two instances of my test program, but only clicking the buttons on one of them before opening the second IE window.) The instance that had registered for events before the "Google" window was opened exhibits the problem. The other instance doesn't, even though they are both registered with the same instance of IE! For this reason I originally thought the issue had to be within AutoIt, but if using DWebBrowserEvents instead of DWebBrowserEvents2 really changes the behavior, I'm at a loss.

I'll try the DWebBrowserEvents event set, as I'm really only interested in the DownloadBegin and DownloadComplete events. Thanks.

launchTest2.au3

[DaleHohm]

Did you look at the amount of time required for $o_sink.stop ?

Dale

[RickyD]

Did you look at the amount of time required for $o_sink.stop ?

Dale

Not really, but it seems pretty fast. However, $o_sink.stop doesn't have to be called in order for the problem to be exhibited. A call to _IEGetObjByID(), for example, will also take an inordinate amount of time to return once the problem occurs. Basically, I've found that once AutoIt registers for events against an IE instantiation, all of the _IE functions I've tried (with the exception of _IEAttach()) have their performance deteriorated if a second window is opened using my test HTML file. This can be shown with my second test program (launchTest2.au3) by simply clicking on the "Restart" button once, and then repeatedly clicking only on the "_IEGetObjByID()" button from that point on. Prior to opening the second IE window, it returns in ~8 ms. Afterwards, it takes ~3200 ms (at least on my system).

I tried using DWebBrowserEvents instead of DWebBrowserEvents2 as suggested earlier, but found that the ObjEvent() call was actually failing. (My quick-and-dirty test program fails to check the return result from the ObjEvent() call.)

Rick

[DaleHohm]

Suggest a test script in VBScript to see if the issue is AutoIt related or not...

Dale

[RickyD]

Suggest a test script in VBScript to see if the issue is AutoIt related or not...

Dale

Pardon the complete newbie question (I've never programmed in VBScript before), but doesn't VBScript run within IE? Will that even prove anything? (Can it even register for events?)

Rick

[DaleHohm]

It runs in IE, but that is not what I was referring to. creating a stnad-alone .vbs file is... sorry you've never done it before... yes, it can do all that AutoIt does with COM but the syntax is different... e.g. CreateObject() instead of ObjCreate().

Dale

[RickyD]

I justed changed this line and it reduced the time.

$o_sink = ObjEvent( $o_IE, "IEEvent_", "DWebBrowserEvents")

No idea if it will break the rest of your project but worked for me.

Something to do with DWebBrowserEvents2? I'm not experience with obj yet but i'm guessing it's something there...

I couldn't figure out why my system didn't seem to support the DWebBrowserEvents interface until I realized that the registry entry for it was missing. Executing the command "regsvc32 shdocvw.dll" restored it.

Using the DWebBrowserEvents interface in my test program caused it to work perfectly. (And it works for my main application too!) I just hope I never need any of the events only available in the DWebBrowserEvents2 interface.

Thanks for the work-around.

[RickyD]

It runs in IE, but that is not what I was referring to. creating a stnad-alone .vbs file is... sorry you've never done it before... yes, it can do all that AutoIt does with COM but the syntax is different... e.g. CreateObject() instead of ObjCreate().

Dale

Dale,

I wrote a VBScript test program, and it didn't exhibit the problem that I have with AutoIt. However, I'm not sure that I was comparing apples to apples for the following reasons:

• The only way to attach an event handler to IE within VBScript is at the object creation time (e.g. with wscript.CreateObject() ). It cannot be done via wscript.ConnectObject(). This is different than how it's done within AutoIt scripts.
• There doesn't seem to be any way of selecting which event interface to use. I can't guarantee that the DWebBrowserEvents2 interface was the actual interface used.

So there may be a problem within AutoIt, but I can't really conclude that I proved it. (Especially since it doesn't seem to happen when using the DWebBrowserEvents interface.)

Rick

[Jfish]

Dale,

I wrote a VBScript test program, and it didn't exhibit the problem that I have with AutoIt. However, I'm not sure that I was comparing apples to apples for the following reasons:

• The only way to attach an event handler to IE within VBScript is at the object creation time (e.g. with wscript.CreateObject() ). It cannot be done via wscript.ConnectObject(). This is different than how it's done within AutoIt scripts.
• There doesn't seem to be any way of selecting which event interface to use. I can't guarantee that the DWebBrowserEvents2 interface was the actual interface used.

So there may be a problem within AutoIt, but I can't really conclude that I proved it. (Especially since it doesn't seem to happen when using the DWebBrowserEvents interface.)

Rick

Are you on IE8 by chance? I too am experiencing problems with the DWebBrowserEvents2 interface and the ObjEvent function. My problem is that I have a snippet of code that creates a browser, pulls data from a database, and navigates. I wanted to listen for the OnQuit event with DWebBrowserEvents2 so I could close the app. When I run it on a machine with IE6 it works perfectly. When I run it on a machine with IE8 I get some strange behavior. After the ObjEvent function is called on IE8 the send function does not seem to run consistently (I am sending values from the DB), the mousemove and mouseclick are also insonsistent, etc. Having said all that - all those things work fine with that interface in IE6. Therefore, maybe this is not an AutoIt issue as much as an IE8 issue???? Or maybe I am doing something wrong on my end :-( Has anyone else tried this interface with IE8 and tried to perform several distinct operations using standard A3 functions in addition to the interface calls (i.e. send, mouseclick, etc)?