Recovery from unexpected windows when waiting for action

without performing an action , how dose TC knows window is unexpected or expected?

for example you may be waiting to popup a window or just waiting

In first instance it's not unexpected second it's expected.... 

We will define the Unexpected window contents inside the 'OnUnexpectedwindow' definition. For example, if you wait to save a large file in a network and it is not accessible for some reason, then you may get a popup stating that the path is not accessible. The properties of this window can be defined and the action can be triggered from the 'OnUnexpectedwindow' function. But it will not get triggered unless there is the next 'Click' or 'DoubleClick' event. If this unexpected popup hides the control to be clicked, then the script will return error instead of handling the event.

In this case, it's not exactly an "unexpected window".  You are expecting the possibility that the path is not accessible and, therefore, should include in your automation conditional code to handle the situation.  "Unexpected Window" in the definition of TestComplete is exactly that... that the window or form that is displayed is completely unexpected and you have no way of planning for it.  So, the event is intended to allow you to build a generic handler to deal with the situation.  Optimally, once such an event is triggered and you see it in the log, you go back to your test automation and build in the aforementioned conditional code to handle the situation... to bullet proof your automation code.

In the situation where you are "waiting" for something else to happen and a pop-up comes up, you could build in to your "waiting" code a timer object to check every few seconds for a pop-up window and to handle it then.  Again, if you know the possibility is there that such a thing could occur, it's not "unexpected"... it is expected but with a lower probability.  So, you build your code "expecting" it to happen so you can deal with it.  Just good programming.

What I mean is that other tools offer things like Recovery Scenario Manager etc. where you can define such scenarios separately (without including all such external situations into your code in each case) and attach it to the scripts when needed. If such a popup is displayed, the recovery scenarios defined will kick in and close the popup. The actual script need not handle it.

This approach can help in defining all the unexpected scenarios separately without making your script code more and more complex. If there are 10 such scenarios that can happen over the duration of a script, then you don't have to repeat this in each script or in each function. 

TestCompelte does not have a Recovery scenario handler separately as far as I know. When I say 'Unexpected', it means that the popup does not occur in a 'normal' case but there is a possibility that it will be shown and we can define the recovery to push the 'Close' button etc.

In that case, right your own "recovery scenarios" as separate modular script code functions or keyword tests that handle the situations you need to handle... this is not different than what I already described.  For example, one recovery scenario is "path not found".  Build a generic piece of code that will execute your recovery scenario for "path not found" instance and then incorporate that into any test case that has the potential for doing so.  Even in what you described, you still need to build out the recovery scenario handler...  TestComplete doesn't have a feature per se called "recovery scenario" but it has the ability and flexibility for you to add any such code to any test case in a modularized fashion.  Again, what you are describing are not "unexpected windows" by TestComplete's definition.. they are "expected possible scenarios" that you need to code for.  Just a matter of doing the code for them.

Obviously, you're used to QTP/UFT... this is a different tool with a different architecture.  What you are asking is possible to do with TestComplete as is, just a matter of doing it.

abinash11:

> But since the 'OnUnexpectedwindow' only works when an action is performed [...]

Actually, it is enough to try to activate some window (e.g. formWindow.Activate() ). If the formWindow is overlapped with some modal window, the OnUnexpectedWindow event will be triggered.

> Actually, it is enough to try to activate some window (e.g. formWindow.Activate() ). If the formWindow is overlapped with some modal window, the OnUnexpectedWindow event will be triggered.

I'm referring to the following limitation:

The check does not happen when the script performs certain operations with window properties or when it executes a function, for example, WaitWindow.

We are testing an application where there are lots of 'WaitWindow' actions due to the response from hardware. Now, during the 'WaitWindow' if a disconnection happens, it can sometimes throw a popup or other errors. Since the system is not stable yet, we cannot predict what will happen and which popup will be shown. This limitation with the 'WaitWindow' makes it unable to handle such cases.