Hi,
We are trying to automate the controls present inside the RadbusyIndicator and not able to access the controls both using CUIT and UI Automation in our application.Similar behavior is observed with CRM Sample application in telerik website (http://www.telerik.com/wpf/sample-applications).Could you please check and provide necessary help in this regard??
Regards,
Nagasree.
5 Answers, 1 is accepted
Thank you for bringing this to our attention.
We were able to observe the behavior in the CRM application. It turns out that the BusyIndicator is over all of the all other elements (not their father) and it is recognized by the CodedUI even it is not visible (due to IsBusy=false) and therefore the elements behind it are not accessible. So there is an easy solution by including all other elements as content of the BusyIndicator as shown:
From:
<
Grid
>
<
TextBox
Text
=
"Simple Text"
/>
<
telerik:RadBusyIndicator
/>
</
Grid
>
To:
<
Grid
>
<
telerik:RadBusyIndicator
>
<
TextBox
Text
=
"Simple Text"
/>
</
telerik:RadBusyIndicator
>
</
Grid
>
So it would be great if you could give it a try and let us know if this approach works for you.
If this is not the case in your project it would be very helpful if you could provide us with a sample project so we would be able to investigate it and get to the bottom of it.
Hope this would help.
Regards,
Georgi
Telerik
Hi Georgi's,
Thanks for the reply.We have suggested the respective development team to check about this.We need a small information about this behavior with Telerik test Studio.
Is CRM application controls are accessible with Telerik Test Studio with old behavior also?
Regards,
Nagasree.
I hope that the suggested approach is suitable for you.
Also, the TestStudio is able to record actions and perform as you expect, even with the old behavior.
So this seems to be due to the fact that TestStudio recorder is locating the elements in a different way - using the WPF VisualTree and the Coded UI uses the AutomationPeers for that purpose.
Please, don't hesitate to write us if you have any other questions or concerns.
Regards,
Georgi
Telerik
Hi Georgi,
Our developers are not ready to modify our application according to your suggestion because it changes the style of the included controls when the “IsBusy” property is set to “True”.
As you mentioned Radbusyindicator is overlapping all other controls, we have tried and succeed to make it work by placing Radbusyindicator at the starting of grid .i.e. just modified the code as
From :
<
Grid
>
<
TextBox
Text
=
"Simple Text"
/>
<
telerik:RadBusyIndicator
/>
</
Grid
>
To:
<
Grid
>
<
telerik:RadBusyIndicator
/>
<
TextBox
Text
=
"Simple Text"
/>
</
Grid
>
We observed that what are controls we have added before RadbusyIndicator in grid are not accessible.
Because we don't have expertise in WPF(or with Teleric), before suggesting this change to application developers we want one clarification from your side. is there any change or impact if we add radbusyindicator at the starting of grid instead of having at the end.
Please let us know for further information.
Regards,
Bhagavan.
By design the BusyIndicator is supposed to work like for other controls and when IsBusy is set to true it disables them in order to indicate that they are not accessible because of some loading in progress. In case that you want the elements inside of the BusyIndicator not to be visible(according to your specifications, If I am not mistaking) you can change the OverlayStyle of the BusyIndicator like this:
<
telerik:RadBusyIndicator
IsBusy
=
"True"
>
<
TextBox
Text
=
"Some Text"
/>
<
telerik:RadBusyIndicator.OverlayStyle
>
<
Style
TargetType
=
"Rectangle"
>
<
Setter
Property
=
"Fill"
Value
=
"White"
/>
</
Style
>
</
telerik:RadBusyIndicator.OverlayStyle
>
</
telerik:RadBusyIndicator
>
So in the case you are describing the BusyIndicator is initially not visible as IsBusy is set to false but its location is over the other elements and once the IsBusy is set to true it is rendered above them and they are not visible.
Therefore moving it before other controls would not the behavior of the application. This would resolve the issue as the BusyIndicator (and its AutomationPeer) would be created before the other controls and when their AutomantionPeers are created they are not blocked by the BusyIndicator as now they are above it. the only concern it this case would be if all of the above the BusyIndicator is covered by controls (depending on your layout and not very probable) as it would not be accessible by the CodedUI.
So it seems like both approaches would work in your scenario as we would recommend using the BusyIndicator as a container, but please bear in mind that we are not familiar with your full specifications and implementation.
Hope this would shine some light on the matter.
Regards,
Georgi
Telerik