Page 1 of 1

Adapter Type is different on different computers

Posted: Mon Jun 12, 2017 10:22 pm
by starstuff
Adapter Type is different on different computers

Hello, I've noticed that the Spy can view UI elements with inconsistent adapter types.
For example: the same UI element is seen as

"/container[@controlname='MainView']"

but on another computer the adapter type is an element:

"/element[@controlname='MainView']"

This has caused issues with running our automation on different computers. Is this a known bug or is there a way to ensure that adapters types remain consistent? The adapter type used to always be a container until recently the SPY on a particular computer viewed it as an element.

Re: Adapter Type is different on different computers

Posted: Tue Jun 13, 2017 8:11 am
by odklizec
Hi,

Unfortunately, there is not enough info in your post to provide a reasonable answer. Please answer the following questions:

Ranorex version?
What technology are we talking about (web/desktop/mobile, wpf, java, mfc, etc...)
Please post a Ranorex snapshot (NOT screenshot) from both computers.
Are you sure Ranorex settings are the same on both machines? Ideally, store Ranorex settings inside solution, so then you can be sure, your project is using the same Ranorex settings on both computers.
Are you sure both computers have installed the same version of system libs (.net, VC runtimes, etc...) or, if used, 3rd party GUI dlls?

Re: Adapter Type is different on different computers

Posted: Wed Jul 05, 2017 10:12 pm
by starstuff
To Answer your questions:

We are using .Net 4.6.1 for a desktop application on Windows 7.
The Ranorex Version is 6.2.1.
I have attached a snapshot of the path tree.

Note on behaviour:

1. When running 32-bit debugging mode on an only 64-bit processor application we get a path error.
2. If we were to run a 32-bit debugging mode on the same application that uses any processor (prefers 64-bit) the paths would be found.
3. Then after running step 2, we run 32-bit debugging mode on an only 64-bit processor application the paths are found without error (same as step 1).

This may imply that something is being cached by Ranorex in step 2 that is used to fix the error in step 1
When we restart the computer, step 1 will no longer work until we do step 2.

Is there anything being stored by Ranorex when running 32-bit debugging mode?

Re: Adapter Type is different on different computers

Posted: Fri Jul 07, 2017 12:19 pm
by qwertzu
Hello startstuff,

Please try to change the Target CPU within the compiling properties of your project to "Any Processor" and see if this solves the issue. You can find this option by opening the properties of your project within Ranorex Studio and navigate to the "compiling" tab.

If this does not help, please also upload a snapshot of the PC on which the elements can be identified, as odklizec already requested.

regards,

qwertzu

Re: Adapter Type is different on different computers

Posted: Fri Jul 07, 2017 11:54 pm
by starstuff
Thanks for the reply, I switched the Target CPU to "any processor" but it still did not work. I have attached a snapshot file.

I have also attached a Target CPU chart to show you what we are experiencing. I am curious as to why the highlighted row does not work. Please note, that it does work if The Top Chart is tested first (Any Processor application (prefers 64-bit)).

Re: Adapter Type is different on different computers

Posted: Sun Jul 09, 2017 10:48 pm
by ahoisl
This is actually the expected behavior - and that's also why you get a technology limitation warning (which also pops up when opening your snapshot) that guides you to the WinForms troubleshooting; Reason #5 is what describes your situation :-)

To correctly recognize WinForms controls, Ranorex needs to load the DLLs containing the definition of those controls. And in .NET you can only load assemblies compiled to the same bit-width as the process you are running in - and all DLLs compiled to "Any processor".

So, if you compile your application to "Any processor", all is fine in every combination - except that Ranorex does not support a 64-bit compiler. That's why you get an error message stating that missing feature when you run a 64-bit process (if compiled to 64 bit or to "Any processor" prefering 64-bit).

If your application is particularly compiled to "64 bit", then Ranorex also needs to run as a 64 bit process. To debug, however, you unfortunately will need to use another tool.
starstuff wrote:Please note, that it does work if The Top Chart is tested first (Any Processor application (prefers 64-bit)).
I can only guess that this is caused by the caching time of the Ranorex Bit Bridge, which stays alive for a default of 60 seconds and caches control definitions. Try killing all "Ranorex.BitBridge*" processes before running the combinations of the lower table.

Regards,
Alex
Ranorex Team

Re: Adapter Type is different on different computers

Posted: Tue Jul 11, 2017 8:59 pm
by starstuff
Thanks for the reply,

Do you know what other tools we could use for debugging? Does this imply we have to leave Ranorex entirely?
Also, do you know if Ranorex is planning to support 64-bit debugging in the future?

Finally, I tested your theory about the RanorexBitBridge and it indeed closes after ~ one minute. However, it still continues to work for 64-bit after one minute (i.e. whatever is cached is not forgotten by the RanorexBitBridge when closed).

Re: Adapter Type is different on different computers

Posted: Tue Jul 11, 2017 10:27 pm
by ahoisl
starstuff wrote:Do you know what other tools we could use for debugging? Does this imply we have to leave Ranorex entirely?
For debugging 64-bit processes you could use Visual Studio. There is a Community version available for free, depending on your company size. And there is Visual Studio Code which is completely free to use and should also be able to debug 64-bit processes.
And you can still use Ranorex Studio to start your tests by switching of debugging (Ctrl+F5 keyboard shortcut), break points will not be hit that way, understandably. As far as I understand, your AUT exists in both 32 and 64 bit, so you may come along with debugging the 32 bit version.
starstuff wrote:Also, do you know if Ranorex is planning to support 64-bit debugging in the future?
This is currently not on our roadmap, I'm sorry. We used to support 64-bit debugging with Ranorex Studio, but felt that we had to invest too many resources to keep it up-to-date with .NET framework development. Our main goal is to invest in automation/testing topics, not fully fletched code IDE features, so we dropped that support with version 6.0.
Until now we had not got a lot of feedback to revive that support, but you may want to start that feature request on our UserVoice site. Thank you!

Regards,
Alex
Ranorex Team