RickyD Posted February 9, 2010 Share Posted February 9, 2010 (edited) 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. RicklaunchTest.htmllaunchTest.au3 Edited February 9, 2010 by RickyD Link to comment Share on other sites More sharing options...
Steveiwonder Posted February 9, 2010 Share Posted February 9, 2010 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... They call me MrRegExpMan Link to comment Share on other sites More sharing options...
DaleHohm Posted February 9, 2010 Share Posted February 9, 2010 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 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 Link to comment Share on other sites More sharing options...
RickyD Posted February 10, 2010 Author Share Posted February 10, 2010 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 Link to comment Share on other sites More sharing options...
DaleHohm Posted February 10, 2010 Share Posted February 10, 2010 Did you look at the amount of time required for $o_sink.stop ? 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 Link to comment Share on other sites More sharing options...
RickyD Posted February 11, 2010 Author Share Posted February 11, 2010 Did you look at the amount of time required for $o_sink.stop ?DaleNot 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 Link to comment Share on other sites More sharing options...
DaleHohm Posted February 11, 2010 Share Posted February 11, 2010 Suggest a test script in VBScript to see if the issue is AutoIt related or not... 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 Link to comment Share on other sites More sharing options...
RickyD Posted February 12, 2010 Author Share Posted February 12, 2010 Suggest a test script in VBScript to see if the issue is AutoIt related or not...DalePardon 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 Link to comment Share on other sites More sharing options...
DaleHohm Posted February 14, 2010 Share Posted February 14, 2010 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 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 Link to comment Share on other sites More sharing options...
RickyD Posted February 17, 2010 Author Share Posted February 17, 2010 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. Link to comment Share on other sites More sharing options...
RickyD Posted February 17, 2010 Author Share Posted February 17, 2010 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().DaleDale, 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 Link to comment Share on other sites More sharing options...
Jfish Posted May 2, 2010 Share Posted May 2, 2010 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.)RickAre 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)? Build your own poker game with AutoIt: pokerlogic.au3 | Learn To Program Using FREE Tools with AutoIt Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now