Jump to content

RickyD

Members
  • Posts

    9
  • Joined

  • Last visited

RickyD's Achievements

Seeker

Seeker (1/7)

0

Reputation

  1. No, since they are external scripts. All I seem to be able to get is the URL of the script file, not the script text itself. Rick
  2. (Edit: Removed stupid suggestion which wouldn't work. Sorry for wasting space.) Rick
  3. I have a web page that I need to get some information from. I've been successful for any information that is actually part of the HTML page (table entries, links, etc.) However, there are a couple of pieces of information that the server side has embedded into an external javascript file. "DebugBar" shows me the script contents, which is how I found what I needed in the first place. I can get the URL of the javascript source file from the document.scripts DOM collection. However, I can't figure out how to read the contents of the script into AutoIt. I've played with InetGet() but haven't had any luck. Is there a way to get the script source directly out of IE? Thanks, Rick
  4. 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
  5. 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.
  6. 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
  7. 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
  8. 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
  9. 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
×
×
  • Create New...