Unexpected behaviour, when application has few main windows : Bug Reports

[slavikf]

Unexpected behaviour, when application has few main windows

Scenario (see scrennshot attached):
- Start application. Open image.
- When image opened, another control appears - FRAME NAVIGATION. It's displayed, as separate window
- Click Menu FUNCTIONS in main Menu bar
Last step fails. Instead of clicking Menu entry mouse goes somewhere in top left corner.
Workaround i found:
Click on main window TitleBar, before clicking Menu Entry.
Just for info:
Ensure Visible = TRUE
Use Cache = FALSE

I thought, that ENSURE VISIBLE Property would take care of that issue... Took me some time to debug and figure out...

[Ciege]

So it appears (to me anyway) that the Frame Navigation form is the active form and not the Main form. So, you tell Ranorex to click on a specific menu item that does not exist, it gets confused and clicks at 0,0.

In addition to EnsureVisible add the MYForm.Activate() call to make sure that the form you want to interact with is the active form. Clicking on the Main window title bar is a roundabout way of activating the form you want to deal with.

*) If you use a general click framework method you should put code to verify the item exists before clicking on it. As well as take an input for the form on which to look so that the method makes that form active (not just visible).

[slavikf]

So it appears (to me anyway) that the Frame Navigation form is the active form and not the Main form.

Yes, you are correct, that Frame Navigation form is Active, but CLICK method explicitly called on object, which is MAIN WINDOW... Why would Ranorex mix 2 windows?

You are correct, that VISIBLE and ACTIVE are two different things... Seems, that where issue is... But i think, it should be possible to click on element, which is not active at the moment. Right? Currently, it seems i need to activate and click it...

[Ciege]

But I think, it should be possible to click on element, which is not active at the moment. Right?

Right or wrong, that is suppose is for Ranorex to decide... Are you using the repository or searching for that object at run time? Is the object rooted to the desktop or the main window or is it relative to the current location?


I am coming at it from the approach of defensive coding of my automation scripts. I want them the be as bulletproof as possible and if it requires me to put a single .Activate line in my custom click method, then so be it.
That being said, most of my automation framework code is full of my own custom verification, try/catch blocks, etc... I want the person writing automation code using my framework to have the greatest possibility of success. As we all know, automation code needs to go above and beyond the success path, we need to account for all (or as many as we can determine) failure paths that can possibly happen and dictate how our automation code is to handle that scenario. If you, like me, have a suite of automated tests that can run for more than 12 hours at a stretch, you may want to put as many defensive steps into your automation as possible as well.

[slavikf]

Are you using the repository or searching for that object at run time? Is the object rooted to the desktop or the main window or is it relative to the current location?

Here is Absolute path to Menu entry:

Code: Select all

/form[@title~'^OIS\ WinStation-11\ EyeScan']/menubar[@accessiblename='Application']/menuitem[@accessiblename='Functions']


I am coming at it from the approach of defensive coding of my automation scripts. I want them the be as bulletproof as possible and if it requires me to put a single .Activate line in my custom click method, then so be it.

Agree with it. But the reason i created this post is to point to one issue with Ranorex, which i think can make life of test developer little harder... So, Ranorex developers can fix that... And make our life easier... That's the reason why we use Ranorex.

[Ciege]

I see your point... I guess I am more comfortable with multiple layers of bubble wrap wrapped around me than most...

[Support Team]

I thought, that ENSURE VISIBLE Property would take care of that issue

Right, Ranorex tries to make an item visible by bringing the window it is located on to the foreground. This usually also activates the form the item belongs to. Anyway, even if ensure visible does not activate your form, Ranorex should be able to get the screen location of the "Functions" menu item unless the form is minimized. Apparently, the MSAA implementation of that menu item only returns valid screen coordinates when the form is active.

IMHO this is not a general problem, but a problem specific to your application. Could you provide us access to your application of a sample application which we can reproduce the problem with? Because only if we are able to reproduce the problem, we can fix it.
Ranorex snapshots of all forms of the application might also help! And if you can provide us snapshots, please, capture them once when the main form is active and once when it is not. Thank you!

Regards and a happy New Year!
Alex
Ranorex Team