This article addresses frequent technical hurdles in Ranorex, from element identification failures to performance optimization and environment configuration.
Before you start
Before troubleshooting specific issues, perform these baseline checks:
- Administrative privileges: Run both Ranorex Studio and your Application Under Test (AUT) as an administrator.
- Instrumentation: Ensure you have correctly instrumented your application or browser.
- System requirements: Verify that your machine meets the minimum hardware and software specifications. For more information, see Hardware Requirements and Software Requirements.
Element identification issues
If Ranorex Studio cannot detect individual controls or shows a "Technology Limitation" warning, try these solutions.
Note: Formerly, the term adapter (or adapter-type) was used to describe the internal representation type of a UI-element. This definition has now been replaced by a more consistent specification distinguishing between roles, capabilities, attributes, and values. The term was also used as part of the RanoreXPath specification which has now been replaced by the term ‘role‘.
Desktop applications without accessibility
Ranorex relies on Windows accessibility frameworks, UI Automation (UIA), and Microsoft Active Accessibility (MSAA/IAccessible), to identify and interact with application controls. If the AUT does not expose accessibility information, Ranorex cannot detect individual elements, and only displays a single “graphic window.”
This limitation often occurs in applications built with frameworks such as WinDev or those that use custom-drawn controls instead of standard HWNDs or accessibility providers.
In these cases, Ranorex must fall back to image-based testing, which is generally less reliable across different machines and display settings.
Recommendations to improve automation reliability:
- Enable accessibility support in the AUT framework (for example, Accessible controls in WinDev).
- Use standard Windows controls where possible.
- Implement a UIA/MSAA provider for custom-drawn controls.
- Verify accessibility using Microsoft tools such as Inspect or Accessibility Insights.
Items not found during execution
Ranorex tracks, identifies, and stores UI elements in a two-step process. UI elements are referenced by an inner representation called repository items. Each repository item abstracts the corresponding UI element with a role and optional capabilities. The position within the GUI is described by a special RanoreXPath specifier that uniquely identifies each UI element.
Tests often fail when the RanoreXPath is too specific or if the UI changes dynamically.
Solution:
Ensure that the AUT reaches the correct state for the UI element to be found within the timeout, use Ranorex Spy to re-track the element, and/or simplify the RanoreXPath.
For more information, see Fix the ‘element not found’ error, UI Elements Identification, and Repository Basics.
Technology limitation warning
Technology limitation warnings usually have their origin in an incomplete instrumentation. It is recommended to refer to Technology Solutions before contacting the Ranorex support team.
If you receive this warning for a CEF application, see CEF and Silverlight application.
CEF and Silverlight applications
CEF
- When testing CEF applications, you may come across a technology limitation warning. For information about potential causes and solutions for these technology warnings, see CEF and SAP applications.
- You may notice when you use Ranorex Spy to recognize UI elements in a CEF AUT, that the highlight rectangle appears offset (Spy highlights a different area than the actual UI element). In this case, set the Force win32 rectangle for dom element CEF plugin configuration to True. This should allow Ranorex Spy to recognize elements accurately and highlight UI elements in the correct location.
Silverlight
Ensure that your Silverlight application does not run in window-less-mode. Set the Windowless property of the Silverlight HTML object to False to allow object recognition.
For more information, see Windowless (Silverlight Plug-in Object).
Data-driven testing
Ranorex supports data-driven testing, which is an advanced key concept of Ranorex. Ranorex supports data connectors for simple data tables, CSV-files, Excel files and SQL database files.
For more information, see Data-driven Testing Introduction.
Speed up Excel data connectors
Especially with large files, the performance of Microsoft’s default file format for excel spreadsheets is getting poor. This weakness might also affect your data-driven test execution.
- Solution: For performance improvements, use the binary file format (xlsb) instead of the default one (xlsx). Simply save your Excel spreadsheet with the extension “xlsb” and assign it to your excel data source.
For more information, see Microsoft Excel-free test execution on runtime machines.
Customizing and extending tests
Extend recordings with user-specified code actions
Easily extend standard recordings with user specific code actions by converting existing action items or by adding a new user code action item to a recording.
For more information, see User Code Actions.
Use Ranorex libraries within Visual Studio
One of the big advantages of using Ranorex is that you are able to use your existing development environment to develop Ranorex based test automation code. Additionally, the code generated by the Ranorex Recorder or Ranorex Repository can easily be integrated into your Visual Studio projects.
For more information, see Visual Studio Integration.
Handling popups and browser interaction
Unexpected dialogs and popup windows
Ranorex provides the dedicated class PopupWatcher to watch for and to handle popup windows. This class allows you to call click actions to close popup dialogs or handle even more complex scenarios in custom callback routines.
For more information, see PopupWatcherLibrary and Handling unexpected dialogs.
Automate a webpage without moving the mouse pointer
Use the PerformClick instead of the normal Clickmethod when working with web adapters likeDivTag, Inputor Link.
For more information, see Invoke Actions.
Environment and execution
Trigger tests from build environments
You can start tests from the command line.
- Solution: Compile your solution into an *.exe file and run it via command line with arguments.
For more information, see Command Line Execution.
Run tests without a Ranorex installation
It is possible to run automated tests on runtime machines without a Ranorex Installation.
- Solution: Create an executable build of your test. Then, you deploy this build to a runtime environment.
For more information, see Introduction to Runtime and Remote Execution.
Known incompatibilities
Some antivirus or security software blocks certain Ranorex functionality.
-
Solution: Temporarily disable the security software or add Ranorex Studio to the allow-list.