Jump to content

DaleHohm

MVPs
  • Posts

    5,930
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by DaleHohm

  1. Many modern forms don't use the Submit action, but rather JavaScript tied to another element that may look look a Submit button - which is why the Click works. Another possibility is that the page may be looking for the "value" of the Submit button that is sent with the form data when a submit button is clicked, but not on a Form Submit action. Dale
  2. The way it works is that the browser sends a "request" to the web server for something. The Server sends back a "response header" that tells the browser the type of content it is going to send back and how many bytes of data to expect (content-length), then sends it. The browser reads data until it gets the expected number of bytes... if the expected number of bytes are not received, the browser will not set its readyState to complete... _IELoadWait sets a timer and loops checking the readyState until it goes to complete or until the default 5 minutes pass (when the LoadWaitTimeout message is given). As SmOke_N said, you can look in IE.au3 at the _IELoadWait function to see how this is done. Dale
  3. The SLEEP() suggestions will not help you in any way. The important message is 6 ($_IEStatus_LoadWaitTimeout) - Load Wait Timeout. This means that _IENavigate waited 5 minutes for one of the sites to finish loading and it didn't. Internally, it is waiting for the document ReadyState to change to 4 or "completed" - you may actually see HTML rendered in the browser, but it still thinks it is waiting for more information from the web server. You can circumvent this default behavior in _IENavigate (it is actually a behavior of _IELoadWait that _IENavigate and many other _IE functions call for you) by passing the NoWait flag to _IENavigate and then putting in your own logic to see if the browser page is ready to work with. _IELoadWait also has a configurable timeout value that you can set... see the helpfile. All that said, what jdelaney suggests is also prudent. Dale
  4. If the documents are actually stored in SharePoint and are being accessed over http(s) by the Groove client app, you may be able to examine network traffic to see where it is actually pointing. You may be able to use netstat or Fiddler (Google them) to see. You may then be able to connect directly, unless the authentication model used throws you another curveball. Dale
  5. See _IEPropertyGet and it's example. Use it to position the mouse pointer and then click with MouseClick Dale
  6. The .Navigate method has no return value, so you must attach to the new IE on your own. I'd suggest that you put the _IEAttach into a loop, waiting for the new window to be found. Something like: While 1 $oIE2 = _IEAttach("http://www.autoitscript.com/forum/", "url") If IsObj($oIE2) Then ExitLoop WEND SmOke_N's method will work too. Dale
  7. #include <IE.au3> Const $ie_new_in_tab=0x0800 $oIE = _IECreate("http://www.autoitscript.com") $oIE.Navigate("http://www.autoitscript.com/forum/", $ie_new_in_tab) $oIE2 = _IEAttach("http://www.autoitscript.com/forum/", "url") _IEQuit($oIE2)
  8. Or $oChildren = _IETagnameGetCollection($oUL, "li") Dale
  9. You can also use .fireEvent method to to trigger arbitrary events. Search the forum or see IE.au3 source to see how it is done. Dale
  10. You may not be allowing enough time for the table to repopulate after clicking next before you try to read it again. Try putting in a Sleep(xxx) to see if it solves your problem. If it does, then use a more sophisticated delay (you may be able to use _IELoadWait on the table or you may have to check it's content more directly). Dlae
  11. Try outputting $htmlResultString somewhere to see if it contains what you expect it to contain. Examine @error after your _IE calls to see what error status might be returned. Dale
  12. Use embedded when you want to wrap a browser instance inside your own UI and controls. Otherwise, much simpler to simply use the full browser. Regarding orphaned processes... make sure that _IEQuit() is called before script exit - normal or abnormal. Dale
  13. I don't see anything in all of what you have posted that shows the string "enGB" that you are trying to select. You need to isolate the control that presents it and figure out how to manipulate it. Dale
  14. There is something unique in the content you are writing to the browser that is causing readyState not to make it to Complete (or 4). Does the browser contain the content that you expect it to contain after the _IEDocWriteHTML? If so, you can bypass the intrinsic _IELoadWait in _IEDocWriteHTML by using _IELoadWaitTimeout(0) before your call and _IELoadWaitTimeout(30000) afterwards to reset it to five minutes. Dale
  15. The element you highlight here is not a form element, but rather a link (<a> tag). You'll need to use _IELink* functions or _IEAction, click to activate it. You will have to drill into the frames, layer by layer. Use _IEDocReadHtml and search the text returned to insure you found your link in the frame. You will also want to set up a COM error handler to see if you might get an Access is Denied error when traversing frames (caused by cross domain scripting). Dale
  16. Pointer to the "pseudo" in my sig... Dale
  17. There was a bug introduced and soon fixed in a version around that time that caused COM method calls to fail silently - only for methods that had no return value like .click and .submit (core AutoIt, not IE.au3). Your workaround is sound, but if you had to do this without compiling, use _IEAction to give the element focus and then use ControlSend to send Enter to the browser window. Dale
  18. See the second example for _IEAction Dale
  19. Check out the second example for _IEAction for a workaround. Dale
  20. _IE_VersionInfo() relates to IE.au3, not the browser. Danp2 is correct. Take a look at my sig for alternatives to _IECreateEmbedded that use the fill browser instance and act as though they are embedded. Dale
  21. My guess would be that the page you are opening is running in a different security zone. This creates a new browser instance and the one returned by _IECreate is invalid. You could play with configuring security zones or if it works if the window is already up, try using _IEAttach after the IECreate. Dale
  22. readyState designates the completion status of a data request made by the browser and the browser's rendering of the returned data. readyState is of little use to you when the request for data is performed asynchronously (using AJAX/XMLHttpRequest methods). The most common way of addressing that problem is to examine some content on the page that changes and indicates to you that the action you were waiting for is complete (look for the existence of an element or look at the content of an element with something like _IEPropertyGet, "outerhtml"). Dale
  23. I assure you they are working "correctly" - it is your understanding of how they work that is incorrect To get the HWND, use _IEPropertyGet($oIE, "hwnd") Dale
  24. The arv is the element that the script is bound to (for=arv). The script is called with an appropriate event on that element triggers it. Dale
  25. Do some things programmatically to insure you are talking to the right element... set it's value, change it's style, etc. Note that the attached onchange event may be messing with you. Dale
×
×
  • Create New...