cancel
Showing results for 
Search instead for 
Did you mean: 

What is the correct way to identify the unexpected window?

SOLVED
Highlighted
Occasional Contributor

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 - confirmattention - errorattention - error

Thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Community Hero

Re: What is the correct way to identify the unexpected window?

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.

 

Regards,
  /Alex [Community Hero]
____
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
https://community.smartbear.com/t5/custom/page/page-id/hall-of-fame
================================

View solution in original post

3 REPLIES 3
Highlighted
Contributor

Re: What is the correct way to identify the unexpected window?

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)


--------------------
QA Systems Architect
Integrated Control Technology
https://www.ict.co/
Highlighted
Occasional Contributor

Re: What is the correct way to identify the unexpected window?

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 - confirmattention - confirm

-----------

attention - errorattention - 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.

Highlighted
Community Hero

Re: What is the correct way to identify the unexpected window?

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.

 

Regards,
  /Alex [Community Hero]
____
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
https://community.smartbear.com/t5/custom/page/page-id/hall-of-fame
================================

View solution in original post

New Here?
Join us and watch the welcome video:
Announcements
Top Kudoed Authors