Upgrade from 5.2 to 5.4 made paths to WPF elements invalid

Technology specific object identification, supported applications, web technologies, and 3rd party controls.
elena.ungureanu
Posts: 19
Joined: Mon Jan 05, 2015 5:46 pm

Upgrade from 5.2 to 5.4 made paths to WPF elements invalid

Post by elena.ungureanu » Mon Sep 21, 2015 4:07 pm

Hello Team,

I've just upgraded Ranorex from version 5.2 to version 5.4 and discovered that paths used to identify elements for a WPF application are not valid any more.

For example the path /form[@automationid='MainWindow' and @ProcessId='{0}' and @Visible='true' and @Valid='true'] is finding now 2 elements under Host node.
However if I'm adding @wpfnative='True' attribute I get only one element, but then the paths used to find elements further down inside the main window are invalid as well. For example /contextmenu/menuitem[@automationid='FileMenuItem'] path used to find 'File' menu option on the main window of the application under test does not find the element. It works if I'm changing the path to //menubar/menuitem[@automationid='FileMenuItem'].

Please see the attachment for a visual clarification.

My question is which is the recommended way to identify WPF elements with Ranorex 5.4: using or not @wpfnative attribute ... and why?
If that attribute should be used, I don't want to think how long will take me to renew the paths to elements under the main window form for the application under test.

Thank you,
Elena
You do not have the required permissions to view the files attached to this post.

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: Upgrade from 5.2 to 5.4 made paths to WPF elements invalid

Post by Support Team » Tue Sep 22, 2015 1:40 pm

Hi Elena,

With Ranorex 5.3 we introduced our new native WPF plugin, see the release notes: Ranorex 5.3.0.
Before Ranorex 5.3 we identified the WPF elements by using the UIAutomation plugin.

Which plugin should be used can be selected in the Plugin settings, with the setting "WPF Legacy/UIA Interaction" as you can see here: Plug-In Specific Settings.

When you were able to identify all WPF elements with Ranorex 5.2, so with UIAutomation and already have a huge repository, I would recommend to either use UiaPreferred or UiaOnly.
This ensures that the existing RxPaths work and that new elements are also identified with UIAutomation and fit into your existing repository structure.
In general, we recommend to use the setting WpfPreferred, this ensures that the old tests still work but also ensures that new elements will be identified by using the new WPF plugin.

Regarding the wpfnative attribute, this attribute indicates that the element is created by the native WPF plug-in. Used for path disambiguation when also using UIA.

In case there remains anything unclear, please do let me know.

Regards,
Markus

elena.ungureanu
Posts: 19
Joined: Mon Jan 05, 2015 5:46 pm

Re: Upgrade from 5.2 to 5.4 made paths to WPF elements invalid

Post by elena.ungureanu » Tue Sep 22, 2015 3:00 pm

Hi Markus,

Thank you for your reply.

Using 'UiaOnly' value for WPF Legagy/UIA Interaction plug-in, all paths used to identify elements are working without any alteration.

But my concern is about future support of this backwards compatibility setting. Currently I'm working on an automation framework built on Ranorex API which grows side by side with the application under test and it is meant to support testing of this product for many years. Also is useful to keep up with latest version of Ranorex as new features are introduced (as the WPF native support), bugs are fixed, support for latest browsers version is added etc.

Plus the way the automation framework is built is to find and interact with a single element at a time (having both representations of one element in the same time is not desirable), so either I'm updating the xpaths for WPF elements to uniquely identify each element or I'm using one of the UiaOnly/WpfOnly plug-in value.

Another problem I'm facing is that if I'm choosing the WPF plugin to identify elements, the structure of the element is different compared to the structure returned by the UIA plugin (as you can see in the screenshot attached to the initial message). This new structure makes invalid all the paths used to identify elements further down within the parent element - for example the path to find 'File' menu option on the SUT main window is different depending on the plugin used to identify the main window (WPF or UIA). I've also sent an email on this matter to [email protected]

The bottom line is that I'm inclined to go for the WPF plugin although this means to review and update the paths used to identify elements for all WPF SUT components.

Regards,
Elena

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: Upgrade from 5.2 to 5.4 made paths to WPF elements invalid

Post by Support Team » Wed Sep 23, 2015 10:31 am

Hi Elena,

Generally, we recommend to use the new WPF plugin, so WpfOnly.
For existing projects, we recommend to use WPF preferred, since this also ensures that the existing UIA paths work and that your existing UIA tests also still work.
For the old repo items, we recommend to step by step migrate them to the new paths, of the new WPF plugin. After all repo items were merged, we recommend to use WPF only.

We can discuss your specific situation via email.

Regards,
Markus

kgasimov
Posts: 16
Joined: Fri Nov 21, 2014 9:55 am

Re: Upgrade from 5.2 to 5.4 made paths to WPF elements invalid

Post by kgasimov » Fri Nov 06, 2015 1:30 pm

Hi,


I'm very curious if your problem is resolved. If so, what was the solution?