Difficulty identifying non-unique menu items

[AdamMackintosh]

Hello, I am having some significant difficulty consistently identifying some particular menu items in an overflow menu.

Our application has a Top Action Bar that has a menu button at the top right. Depending what View you are on, you will get options such as Reset, Create, Search, Sort, Help.
1) Create is always the first item in the list, except one view that has Reset first.
2) No matter which view I am on in the app, when i add a repository item for /cell[@localizationkey='overflowMenu_createButton'] it finds 4 matches.
3) I have attached a snapshot of this item

If I change the repository item to something more specific like /container[12]/table/?/?/cell[@localizationkey='overflowMenu_createButton'] Ranorex finds it, but next time I run the application, the container[12] rigid identifier changes to something like container[7] and it cannot find it. As I alluded to above, every time Ranorex encounters this overflow menu with Reset appearing first, it always taps on Reset instead of Create. This is how I know Ranorex is observing the other overflow menus that havent been accessed yet, because it is searching for "/cell[@localizationkey='overflowMenu_createButton']" and finding it somewhere in the backstack of activity views and clicking on it which is causing it to hit the active view's Reset menu item.

My issue is that I cannot seem to stop it from doing this. I think it is because I can never narrow the matches down to 1 because there is no unique attribute for the create button that I can latch onto.

Can anyone help me uniquely identify this particular button, or arm me with some techniques to avoid this type of non-unique matching.
I can get upwards of 11 matches for overflow menu items because they are all somehow active even though only 1 is "actually" visible on the screen.

I dont understand, but iOS seems to give me a horrendous selection of attributes for every element compared to our web platform. Why is this the case? Our iOS developer has stated that it will take a long time to add unique identifiers to every element with something like an id=CreateButton1 id=CreateButton2 (etc.). Is there another way that I cannot see so far? In web, I can always find something and I also never have these issues with Ranorex being able to see and detect every instance of an element such as an overflow menu item because it normally restricts itself to the view it is looking at, not everything else in the background. In web, if I tell Ranorex to click on the first create button it sees with a repository item like .//a[@innertext='create'], it always does it because the menu is open and there is only 1 create button in the menu. Why does iOS see 11 overflow menus when only one is open on the screen? Is there a way I can tell it to ONLY examine what is on the screen?

Thanks,
Adam

[AdamMackintosh]

Here is a snapshot of what I think is our entire iOS app, if it helps anyone figure out what I am talking about.

My first issue is that every time I add a repository item, there are next to zero attributes that can be used to dynamically identify the item.

My second issue is magnified by the first issue because the only attributes I can latch onto are also used by like a dozen other elements throughout the application, and Ranorex can see all of them when it goes to click on the only one that is actually visible on the screen.

I tried to do some fancy dynamic repository items that would examine the view title of the view it was on and then look for the first create button it sees, but it was still not uniquely identifying it because the title bar exists ABOVE the view it was on, so it was still able to observe all 4 create buttons, and it still clicks on the Reset button on the problematic view.

[Support Team]

Hello Adam,

Thank you for the detailed description. Unfortunately, your first snapshot is empty and I am not sure if the second snapshot shows the elements you are talking about.
However, I can see in the second snapshot that almost all elements have an AccessibleLable attribute which could be used in order to recognize the element.
I can also see that there are a lot of container elements containing exactly the same "Create", "Sort" and "Help" element. Unfortunately, the path to the "cell" elements seems also to be the same.

MultipleContainersAndElements.png

The problem is that Ranorex has to decide, which is the correct one and uses the index, but the index seems to change very often. So using the index will not help.

I can also see that the visible attribute is set to true for one particular container and not for others.
Maybe you can use this attribute in order to get the correct element.

For example using a similar RanoreXPath like the following:

/mobileapp[@title='com.verified.Whistler']/form/container[@platformclass='UIView' and @visible='true']/container[@platformclass='UIView' and @visible='true']//table//text[@accessibilitylabel='Search' or @accessibilitylabel='Create' or @accessibilitylabel='Sort' or @accessibilitylabel='Help']

If this doesn't work, would it be possible to give us a copy of your app? Maybe we can find a better solution or a workaround for you.
If you don't want to post it to the public forum you can also send it to [email protected] .

Regards,
Bernhard

[AdamMackintosh]

Thanks a lot, I will investigate those two observations you made and see if I can hone in on anything. I am liking your visible=true for the active one. That might be the trick for me in this case.

I will report back as soon as I can find something new.

[AdamMackintosh]

I am seeing all 4 create buttons as visible=true while i am viewing one of them, and I am also seeing 4 matches when i add accessibilitylabel='Create'

The Container however, does seem to be visbile=true only for the active menu, so i think i can use this path snippet here to clean it up

/container[@visible='True']

[AdamMackintosh]

That worked. I was able to identify everything in the app using container visible attribute, but now I'm having an issue on a specific view that seems to detonate Ranorex and cause it to disconnect from the device.

The path to the item I am trying to tap is ../container[1]//titlebar[@accessibilityid='Albums']/button[@accessibilitylabel='gen menu']

When I click edit or load any type of spy/tracking, it says "No element was found for the parent folder of the selected repository item."

Currently, that path is /mobileapp[@title='com.verified.Whistler']/form/../container[1]//titlebar[@accessibilityid='Albums']/button[@accessibilitylabel='gen menu']

But it still says that if i back everything off and just try and view /mobileapp[@title='com.verified.Whistler']/form/

I cant get a snapshot because nothing loads in the BROWSER & RESULTS tab of spy. You might be able to use my previous snapshot of the entire app.

Anyone have an idea why this view in our application causes this issue. I believe it may be related to the DOM and/or base repository/ranorexpath values, but I don't know how to go about diagnosing that.

Thanks,
Adam

[odklizec]

Hi,

The path you used tries to find Container[1] one level up (/../) from the current element (Form).

Container.png

But as you can see, there there is no descendant "Container" under MobileApp!

What you probably wanted to use is this path?

Code: Select all

/mobileapp[@title='com.verified.Whistler']/form//container[1]//titlebar[@accessibilityid='Albums']/button[@accessibilitylabel='gen menu']

But I'm afraid, there is no button with accessibilitylabel='gen menu' in the snapshot you provided, so I'm not quite sure about this path either?

Also, using Container[1] means that even if there is another Container containing //titlebar[@accessibilityid='Albums']/button[@accessibilitylabel='gen menu'], it will be not found, because it's not in directly specified Container[1]. So I would suggest to drop the index.