The different timeouts in iMacros
Timeout as macro variable
There are three different timeout macro variables in iMacros:
- Infinity by default. By setting it you limit the total time the complete macro is going to run before it is aborted with error code = -1930, and the following message: "A timeout of x seconds set by !TIMEOUT_MACRO variable has exceeded."
- This variable does not have any dependency with the other timeout variables.
- It governs the maximum time iMacros waits for a single page to load, before stopping with error = -1330 and message "A timeout of x seconds set by !TIMEOUT_PAGE variable has exceeded."
- !TIMEOUT is the same as !TIMEOUT_PAGE.
- It sets the maximum time iMacros waits for a single file to download, before stopping with error = -1330 and message "A timeout of x seconds set by !TIMEOUT_DOWNLOAD variable has exceeded." If no value is given, iMacros uses !TIMEOUT_PAGE.
- !TIMEOUT_STEP, also !TIMEOUT_TAG
- It controls how long (at most) iMacros tries to find an element (html, or image) on the page. If no value is given, iMacros uses 1/10 of !TIMEOUT_PAGE, although changing !TIMEOUT_STEP won't affect !TIMEOUT_PAGE.
- When playing a TAG, IMAGESEARCH, or IMAGECLICK command, iMacros looks for the element on the page once and waits what we call a "load check interval" (currently 1 second). Then it looks for the element again, and again, and as many times until it is found or !TIMEOUT_STEP is reached. In other words, !TIMEOUT_STEP is the number of times iMacros is going to retry the command (only TAG and IMAGESEARCH/CLICK). Setting !TIMEOUT_STEP to 0 (zero) leads iMacros to run the command only once, and setting !TIMEOUT_STEP to 10, for instance, will cause iMacros to process the subsequent TAG and IMAGESEARCH commands up to 11 times, if the element is not found before. That is, it waits for it 10 seconds at most.
- When the element is not found within !TIMEOUT_STEP, iMacros stops with error = -1300 (or -1800 in case of Imagesearch), unless !ERRORIGNORE was set to YES.
Timeout as Scripting Interface method parameter
There is also the timeout that can be set in some Scripting Interface methods calls: iimOpen, iimPlay, iimPlayCode, iimExit, iimDisplay. This timeout is the time the scripting interface waits for a response from the browser that is being automated, and has no correlation with the three iMacros timeout variables. In particular, the timeout set in iimPlay can be easily confused with !TIMEOUT_MACRO, but while setting iimPlay's timeout to a lower value than necessary to run successfully the macro in question will cause iimPlay to return a timeout error (-3, in this case), the browser will keep playing the macro until its end or will stop because it has lost the connection with the scripting interface. The latter is logged in iMacros.log. The scripting interface timeout is important to avoid freezing the calling script or program in case the browser becomes unresponsive.
iMacros Sidebar for IE command line argument -timeout
iMacros Sidebar for Internet Explorer also accepts a timeout command line argument -timeout which tells the sidebar how long to wait for Internet Explorer before giving up and exiting.
Many times when starting the iMacros Sideabr for Internet Explorer, one sees that IE starts and while is loading the homepage, the sidebar issues a popup informing that IE is busy and exits. This occurs even before the sidebar appears. If the network connection is slow, IE homepage is heavy and not cached, the time the sidebar waits for IE to respond (before appearing itself) reaches its timeout and the sidebar exits. In such situations is advisable to increase the iMacros Sidebar timeout.
Notice that it is not necessary (nor accepted) to use this parameter when starting iMacros Sidebar from the scripting interface (with iimOpen) because the sidebar will use the value given in iimOpen's timeout parameter as the maximum time it waits for Internet Explorer to respond.
Timeout in the iMacros Component for .NET
As explained above, the iimPlay timeout is the maximum time the scripting interface itself waits for an answer from the browser, before returning the control to the calling script. Now, with the component, *you* are the browser itself. So, this timeout makes no sense. Imagine the following situation:
Alice is the the scripting interface, and Bob the browser. Alice's mother (the controlling script) says "Alice, tell Bob to get some milk from the grocery store. I can only wait 30 minutes." So, Alice says to Bob: "Go to the grocery store and bring milk." It makes no difference to Bob that the mother only wants to wait 30 minutes. He will go and try to get some milk even if it takes a really long time. Alice, on the other hand, keeps the clock. After 30 minutes, if Bob is not yet back with the milk, she simply tells her mother that unfortunately Bob is not back yet, and if she wants, she can abort the trip to the supermarket (iimClose kills the process), without the milk.
When we consider the scenario above in the context of an application that uses the iMacros component, Bob becomes the component (just like the iMacros Browser) and there is no Alice or Alice's mother. That is, of course, unless you decide to implement your own Alice (scripting interface) to work specifically with your iMacros component-based application. Then you could provide your own equivalent to the iimPlay timeout.
- The variable !WAITPAGECOMPLETE has no effect on any of the timeout variables. Setting !WAITPAGECOMPLETE to YES or NO changes when iMacros assumes that the page is fully loaded.
- If your macro contains one or more WAIT commands, the time the macro needs to run is the total time, including all the time it waits forcefully at a WAIT. If you have set !TIMEOUT_MACRO to some finite value this might cause the macro to be aborted before it is complete.
- Since !TIMEOUT_STEP is 1/10 of !TIMEOUT_PAGE by default and only integral numbers are accepted, setting !TIMEOUT_PAGE to a value lower than 10 will cause !TIMEOUT_STEP to be 0, unless you have explicitly set it to a different value.