There are situations when object location attribute depends on the object data and it is not possible to record/learn all such objects in advance. In this case it may be convenient to calculate object location at playback time using FormatString and SetLocatorOpts actions of the RVL global object.
It is a common situation that desktop applications written using Microsoft Windows Presentation Framework (WPF) will have complex layouts including tabs, splitters and panels having custom grids and tables inside. This article provides help in dealing with such situations, including how to dynamically find items.
When testing Silverlight applications, you may find that Rapise fails to recognize the objects in the Silverlight app using the UIAutomation library. When using the Rapise Spy Tool, the whole app is identified as a single window. The objects such as a dropdown, buttons etc. inside the silverlight app are not individually recognized.
Sometimes you will have controls in a WPF or Silverlight application which use dynamic lists. Depending on certain settings, the widgets in the list will appear in different places. This means that a learned Rapise object which works fine if its in the original ListBox[0] location position is not found during playback when it's displayed in another position, e.g. ListBox[1] or [2].
Unlike the XPath option with web testing, Rapise doesn't currently allow regular expressions (Regex) in locators stored inside the Objects.js file. This article describes a way around the problem.
This article is obsolete. Rapise supports regular expressions in UIAutomation locators since version 6. Read this article for more details.
We had a customer request for a sample that demonstrates how to click on buttons in a desktop application (in this case a plugin for Microsoft Word) where instead of having to learn each of the buttons individually, you can learn the button container and then loop through the buttons using a Rapise RVL Map.
Rapise 6.3 includes an experimental feature - new UIAutomation2 locator for UIAutomation based desktop testing. Rather than specifying a path from the element tree root to the element this locator relies on built-in ability of UIAutomation to search for elements based on property values.
UI Automation is a default technology for testing desktop applications on Windows. If your application is not .NET or Java then Rapise will turn on UI Automation library during recording. If some elements in your application are not recognized or there are issues with playback of recorded steps then most likely your application is using custom UI controls. You may inspect those controls and send information to Rapise support team to get recommendations on how to proceed with testing.
This article is for those who test a desktop application via UI Automation library. Since desktop applications are frequently built using UI controls from different vendors and the number of such controls available on the market is pretty big (> 1k) - Rapise may not have out-of-the-box support for some controls in your application. For such cases Rapise offers a low level API to navigate UI Automation tree of elements inside an application and read/write element properties. In this tutorial we'll show how to use this API and quickly add minimal support for a custom control.