In my application where I build my automated tests, several unexpected windows appear (error window, window to confirm by clicking OK, window to decide to click yes or no), I would like to gradually map these unexpected windows and deal with the function assigned there in GeneralEvents> OnUnexpectedWindow. Following the example of the documentation I have this role assigned to OnUnexpectedWindow: function GeneralEvents_OnUnexpectedWindow (Sender, Window, LogParams) {inside this function I would like to place the filters:(pseudo)if (windowAppeared == Confirmation){>click OK<} if (windowAppeared == error){>print log<>halt execution<}} In my case it is a very complex application. Is a good approach? I'm having trouble to identifying the windows, because some are external applications (window to print a pdf, timeout error connection to server). Windows don't always have the same properties, so what is the correct way to identify the unexpected window? in some I use Caption, in others I can't use Caption property and I'm using ObjectIdentifierSamples of windows:attention - confirmattention - errorThanks

Hi, To make it second to what was said by tphillips : By definition, the unexpected window in TestComplete is the window that blocks user input and that is not referenced in test code. If the window fits the above criteria, the OnUnexpectedWindow event will be triggered. Note, that in order to be treated as unexpected, the window must block user input, i.e. to be system- or application modal and prevent activation of the window/control that test code tries to interact with. So, in most cases, the OnUnexpectedWindow event is triggered by the .Activate, .Focus, .Click and .Keys methods and the most reliable way to detect unexpected window is to call .Activate or .Focus methods before trying to .Click or .Keys the window or control respectively for desktop applications. Note, that if your test code does not interact with the application via GUI but uses direct assignments (e.g. via the .SetText method) the OnUnexpectedWindow will not be triggered because nothing prevents the target control to be interacted with. If your test code explicitly waits if the modal window exists and processes it if it does, then, as it was said by tphillips, this window will not be considered to be unexpected and the OnUnexpectedWindow event will not be triggered.

joaobc

Occasional Contributor

5 years ago

What is the correct way to identify the unexpected window?

In my application where I build my automated tests, several unexpected windows appear (error window, window to confirm by clicking OK, window to decide to click yes or no), I would like to gradually map these unexpected windows and deal with the function assigned there in GeneralEvents> OnUnexpectedWindow.

Following the example of the documentation I have this role assigned to OnUnexpectedWindow:

function GeneralEvents_OnUnexpectedWindow (Sender, Window, LogParams) {

inside this function I would like to place the filters:

(pseudo)
if (windowAppeared == Confirmation)
{

>click OK<

}

if (windowAppeared == error)

{

>print log<
>halt execution<

}

In my case it is a very complex application. Is a good approach?

I'm having trouble to identifying the windows, because some are external applications (window to print a pdf, timeout error connection to server). Windows don't always have the same properties, so what is the correct way to identify the unexpected window? in some I use Caption, in others I can't use Caption property and I'm using ObjectIdentifier

Samples of windows:
attention - confirmattention - error

Thanks

AlexKaras
5 years ago
Hi,

To make it second to what was said by tphillips :

By definition, the unexpected window in TestComplete is the window that blocks user input and that is not referenced in test code.

If the window fits the above criteria, the OnUnexpectedWindow event will be triggered.

Note, that in order to be treated as unexpected, the window must block user input, i.e. to be system- or application modal and prevent activation of the window/control that test code tries to interact with.

So, in most cases, the OnUnexpectedWindow event is triggered by the .Activate, .Focus, .Click and .Keys methods and the most reliable way to detect unexpected window is to call .Activate or .Focus methods before trying to .Click or .Keys the window or control respectively for desktop applications.

Note, that if your test code does not interact with the application via GUI but uses direct assignments (e.g. via the .SetText method) the OnUnexpectedWindow will not be triggered because nothing prevents the target control to be interacted with.

If your test code explicitly waits if the modal window exists and processes it if it does, then, as it was said by tphillips, this window will not be considered to be unexpected and the OnUnexpectedWindow event will not be triggered.

tphillips
Frequent Contributor
5 years ago
The most robust way is probably to look at the text in the window and see what it's saying, to identify which window it is.

This prompts another question, are these windows actually unexpected? If it's asking if you want to save, surely that's expected given the actions leading up to the window appearing? (e.g. making changes and not explicitly saving them)
- joaobc
  Occasional Contributor
  5 years ago
  Correct, I have to agree with you that the best way is to identify all or part of the text that identifies the window. And I've been doing it this way. But it doesn't always work or rather saying, it doesn't seem to be a very efficient way.
  
  However, by example the two are practically the same, only the last sentence in the window is different.
  And now for each of the windows, let me share its properties that partially contain the window text:
  attention - confirm
  -----------
  attention - error
  
  In attention - error I can easily identify, but in attention - confirm blank spaces are changed by underline and need a special treatment in the property to check text.
  
  My search was to find some property common to all windows, but as can be seen there is not always a pattern. I guess the best way is to use Find () from the main process by passing the parameters of the object property and raw value (like images above) and checking if the Find returned the object from the window or not.
  
  About not being an unexpected window. The normal part of my application is to work with it in ONLINE mode, however I already do a validation that if the window that is not communicating appears I do it in OFFLINE mode. My script changes the application to OFFLINE mode and then there are these various confirmation and error windows, which are expected, but I would like that when they appear, the test complete automatically clicks the OK button, or NO or CLOSE.
AlexKaras
Champion Level 3
5 years ago
Hi,

To make it second to what was said by tphillips :

By definition, the unexpected window in TestComplete is the window that blocks user input and that is not referenced in test code.

If the window fits the above criteria, the OnUnexpectedWindow event will be triggered.

Note, that in order to be treated as unexpected, the window must block user input, i.e. to be system- or application modal and prevent activation of the window/control that test code tries to interact with.

So, in most cases, the OnUnexpectedWindow event is triggered by the .Activate, .Focus, .Click and .Keys methods and the most reliable way to detect unexpected window is to call .Activate or .Focus methods before trying to .Click or .Keys the window or control respectively for desktop applications.

Note, that if your test code does not interact with the application via GUI but uses direct assignments (e.g. via the .SetText method) the OnUnexpectedWindow will not be triggered because nothing prevents the target control to be interacted with.

If your test code explicitly waits if the modal window exists and processes it if it does, then, as it was said by tphillips, this window will not be considered to be unexpected and the OnUnexpectedWindow event will not be triggered.