Why does Coded UI Test playback fail to scroll the Silverlight control into view?

Bringing the control into view is an essential part of the UITestAction during Playback since Coded UI Test performs actual Mouse/Keyboard actions on the control instead of programmatic action on the control. In case of failure to bring the control into view, the playback will throw a FailedToPerformActionOnBlockedControl exception or a PlaybackFailure exception.

The Coded UI Test playback engine attempts various approaches to bring the control into the physical screen view –

-          Bring the application window into the screen area
-          Set focus on the control.
-          Scroll the control into the view port of the container within which it resides.

This post focuses on the third approach and the assumptions made in the scrolling logic for Silverlight test automation in Coded UI Test.

To scroll a control into view,  the control (or its accessibility peer) should either support the scrolling capability natively,  or needs to be residing inside one or more scrollable containers which can then be scrolled in some sequence to bring the control into view.

Silverlight controls such as ListBoxItem or ComboBoxItem have their AutomationPeer implement IScrollItemProvider which is used to scroll the item into view. [The  ComboBox scroll into view in Coded UI Test is actually done through a select mechanism]

Read more: Tapas Sahoo's Blog

Posted via email from .NET Info