New Qt vs. Qt Legacy mode

[MikeV]

Ranorex Studio 5.2.1. We are using the Qt plugin.

In Global Settings, there is an option "Use QT legacy automation mode", True or False. When this is set to False, some of our Qt elements are identified in more detail by Ranorex Spy, but others that used to show more detail are no longer showing that detail.

Many of our tests that try to find Qt elements are now failing when the flag is set to False. And we want to take advantage of the better Qt identification of some elements when the flag is set to False. But we can't have a situation where hundreds of tests are failing when the flag is set to False.

Is there a way to programatically set this flag, so we can change it from True to False, or vice versa?

[Support Team]

Hello MikeV,

you can en/dis -able the QT legacy mode using following code snippet:

Code: Select all

Configuration.Current["plugins.qt.legacymode"] = true/false;

Please note that complications can arise if you are using folder caching.

Hope this information helps.

Regards,
Robert

[MikeV]

Robert,

I will try your suggestion when I get back into the office, beginning of January.

Thanks!

[MikeV]

Robert,

The suggested code seems to be working well for us. We are using VB, so the format is to set the flag to True:

Ranorex.Core.Configuration.Current("plugins.qt.legacymode") = True

right before the xpath identification we want to work the old way, and set it back to False immediately afterwards.

Thank you!

[MikeV]

Upgrading to Ranorex 5.4 broke our build wherever we were using this:

Ranorex.Core.Configuration.Current("plugins.qt.legacymode") = True (or False)

So something in Ranorex obviously changed, and we need to know how to change our code to handle it. I have simply commented out those lines for the time being, so we can get our solution to build. However, that means that approximately 200 of our tests are again failing.

If there is an alternate method of changing the Qt Legacy flag programmatically, please let us know what that is.

[odklizec]

Hi,

I guess your problem with 5.4 is related to this breaking change, mentioned in 5.4 release notes...

Some Ranorex classes in the Ranorex.Core assembly, which were public, but not documented and not intended for public use,were moved to Library DLLs -> if you use such internal APIs, you have to add references to the Ranorex.Libs.* assemblies in order to build your Ranorex projects. Note though, that some of these APIs are marked as obsolete and will be removed in future versions of Ranorex

[Support Team]

So something in Ranorex obviously changed, and we need to know how to change our code to handle it.

As odklizec already supposed, the CaseInsensitiveString type was moved, because it is intended for internal use only. You can still add a reference to the Ranorex.Libs.Util.dll to use it.
We are going to add an overload of that Configuration class property taking a string so that adding a reference to that DLL is no longer necessary.

Regards,
Alex
Ranorex Team

[MikeV]

Thank you for your comments with this valuable information! I have been busy with lots of manual testing on a new product lately, so I have not had time to implement that change in our Ranorex code yet. When I have time, I will report how it goes.