Control Manager question (if the window isn't there...)

[snowsnowsnow]

I have a few questions about how CM works when you are trying to get a handle of a window that may or may not be there.  I've done a fair amount of experimentation, but the results are inconclusive.  I'm looking for the straight poop from someone who knows; not really interested in random suggestions.

Now, suppose I have a line like:

window1=cWndByWndSpec("Something","Something",3,67556,67554,67536)

Originally generated with RoboScripter, now integrated into my own script.

The question is: If the window isn't there, what does the above line do?

The answer is, eventually, assigns zero (0) to window1 and the script continues.

This raises a few questions:

1) How long does it wait?

2) Is it burning the CPU during that time?

3) Why doesn't it cause the script to fail (as will happen with most other functions, that return zero, assuming no error trapping is in effect) ?

The answers, as far as I can tell, are:

1) 9 seconds - unless you've changed this with a certain IntControl() (I haven't bothered to look it up - but I have messed with it in the past).

2) Yes - so if you are doing this in a loop - you need to do a TimeDelay between attempts, or else you'll use all the CPU.

3) Because that's the way it is in CM.  Essentially, this means that you need to manually check the value returned from each CM function call.  This is a PIA, and note that it is easy to get complacent about this - given how the rest of WB works.  Also note that DllHwnd() is like this, too; it will wait the 9 seconds then quietly return zero (without bombing the script).

Have I got this all right?  Anything to add or correct?

Note that I think there is some variation (and some dark corners) among the various CM functions in this area.  Some of them, I think, do bomb the script if they fail; but others don't.

[td]

Answers based on the current version of the extender.  The details of how the implementation works have changed over time so the answers only apply to the lastest version.

1) How long does it wait?

The extender default is to retry 20 times.  This particular extender function waits 20 milliseconds between retries.  That makes for a total of 400 milliseconds of wait time.  However, the function's task is CPU intensive so the actual time to return is longer and largely depends on the horsepower of the system running the script.

Note that you can set the number of retries to your own preference using the extender's cSetWndSpecRetry function.

2) Is it burning the CPU during that time?

The "burning" is the result of the function performing the window search, not the result of waiting.  As previously mentioned, the function is CPU intensive.

3) Why doesn't it cause the script to fail (as will happen with most other functions, that return zero, assuming no error trapping is in effect) ?

The function is designed to be more flexible than other WIL functions.  Flexibility is why we have extenders that offer alternative approaches to solving problems.  Rigid consistency is the hobgoblin...