DevExpress XtraNavBar NavBarControl not a supported control?

[Ciege]

Is the DevExpress XtraNavBar NavBarControl not a supported control?

Currently in my AUT my dev team has implemented a portion of out AUT that utilizes this control. Ranorex can see that the navBarControl exsts but cannot obtain any information from it.

I am using Ranorex version 2.1.4.

Thanks...

[Support Team]

Works for me with DevExpress 8.1 and 8.3, Ranorex can get all information from it. The elements inside the XtraNavBar.NavBarControl usually have the 'Link' role and are created by the MSAA plugin.

What version of DevExpress do you use?

Regards,
Alex
Ranorex Support Team

[Ciege]

We are also using v8 of the DevExpress controls.

Once I manually get the groups open (Main, Forms, etc... in my attachment) by manually clicking the drop down button I am able to read all the controls underneath same as you (although we are using a tree control here).

The problem is, I cannot get Ranorex to access the group drop downs buttons to open them. It doesn't see the group headers or the drop down buttons that live on the headers.

So how do I get the group boxes open via the drop button to then be able to get at the bits underneath?

Can you access the group drop down buttons in your example?

Thanks!

[Ciege]

Hey guys... Any update as to how I can access the NavBar group drop down buttons? Since Ranorex can't see them to open them, I cannot then access the controls that live within the groups.

Thanks...

[Support Team]

Hi Ciege,

It took me some time to look into that issue and it seems that Ranorex filters the MSAA elements corresponding to the group boxes. The group boxes do not provide a useful AccessibleRole ("Client"), that's why Ranorex filters them out.

The problem is now that we can't just change our filter algorithm because of backwards compatibility. If we'd show such MSAA elements by default, many RanoreXPaths could change because of the newly not-filtered elements (many of your paths could suddenly not work any more). We could just provide some flag that enables or disables the filtering of such elements for exactly that type of control.

Sounds like some really bad workaround just for the sake of backwards compatibility. Or do you have any better ideas?

Regards,
Alex
Ranorex Support Team

[Ciege]

Better ideas? well that could mean a lot of things... Best idea is for you guys to do all my automation coding and let me stay home and collect a paycheck! Short of that...

I've been trying to figure out a way to use InvokeRemotely to do this for me, but I have not figured the correct way to do it. If you could help with designing that functionality that would be most beneficial.

As for showing the filtered MSAA elements. Can we turn that on and off at any given time or is it on or off at execution time of the project? If we can turn it on or off at any time, I could turn it on when searching for the group boxes then turn it off after my search is complete...

Thanks!

[Support Team]

As for showing the filtered MSAA elements. Can we turn that on and off at any given time or is it on or off at execution time of the project? If we can turn it on or off at any time, I could turn it on when searching for the group boxes then turn it off after my search is complete...

You can turn the filtering on and off at runtime. And the best thing is: there is already such a flag in the MsaaFlavor class. I.e. the following code line should turn the filtering of MSAA elements off completely, then you should be able to find an element corresponding to the group boxes:

Ranorex.Plugin.MsaaFlavor.Instance.FilterEnabled = false;

The only bad thing about disabling the MSAA filter is that other paths could happen to not work any more. So, be sure to turn filtering on again after you got an instance to the group box elements.

In order to disable filtering in the Ranorex tools, you can use a simple plugin that contains the above code line. I've posted the source code for such a simple plugin in the following post: http://www.ranorex.com/forum/wpf-listvi ... html#p3617
Simply add the above code line at the specified extension point and place the DLL to the specified Plugins folder, then filtering should be disabled in Ranorex Spy.

Regards,
Alex
Ranorex Support Team

[Ciege]

Thanks! I'll give this a try later today. I currently have another test running at the moment.

[Ciege]

Great! That seems to work fine. I can now find the group boxes. Although the dropdown button is not an object that I can find, I can invoke the accessible default action of the group boxes (which is either expand or collapse) and now get the objects below the group box headers.

Thanks!

[Support Team]

Great you could get that to work without the need for a new Ranorex version

Regards,
Alex
Ranorex Support Team

[Ciege]

Note to self... Remember, remember, remember to remove the plugin (to enable RanorexSpy to view the group headers) before running the suite of tests (even through Visual Studio). Even though I am turning on/off the filtering in my code when needed, I had to have the plugin installed so I could examine the objects in RanorexSpy.

It took me almost 2 hours to try and figure out why things that have been working for months suddenly broke with my new build of the AUT...

At least it's almost Friday!

[Support Team]

Plugins in the "Plugin" directory are loaded for all Ranorex applications, even for those you create yourself.

At least it's almost Friday!

It is already here in Austria

Regards,
Alex
Ranorex Support Team