Forum Discussion
Hi Shankar,
Personally I would stick to OnUnexpectedWindow event. You may have additional details for your use case that will invalidate this approach, but my current reasons are like this:
a) Generally, it is a good practice to call .Activate() or .SetFocus() methods before using the mouse or .Keys() method. If the target window/control cannot be activated because of been blocked by some modal window, this will trigger OnUnexpectedWindow event and you will be able to process the blocking window without any performance penalties due to constant check whether or not the blocking window exists;
b) If the window of your interest is not a blocking one then this means that it will not block user from doing the job, the user is not forced to close it before he/she can continue to work and, depending on implementation, the window may even appear to be behind the application/form and be noticed when the task is done. In this case it may be enough to check for the window presence before and after the test does its job.
- shankar_r7 years agoCommunity Hero
Thanks AlexKaras for the inputs,
In my case, AUT will be invisible during that window comes.
I tried use SetFocus() or Activate() method but the new window is not considering as unexpected window.
Log will just saying the your Main window is invisible thus can't be activated.
- AlexKaras7 years agoChampion Level 3
Well... Usually, TestComplete can access properties of the invisible object that exists. So, if the main window still exists but is hidden when the additional window is opened (what was the reason for such design..?), what if you check whether or not main window is visible before any UI action (mouse, keyboard) and proceed appropriately ?
Related Content
- 3 years agoWarseng
- 12 months agonastester
- 5 years agokaiiii
- 2 years agojaredjamieson
Recent Discussions
- 3 days agoMW_Didata