Interacting With Non-Compatible Application Objects

Applies to TestComplete 15.68, last modified on October 03, 2024

TestComplete provides a number of test objects corresponding to various controls in applications and uses these test objects to record and play back user actions on the controls. Each of these test objects has a number of methods and properties you use to perform various test operations on controls, for example, getting control text, selecting check boxes, clicking items in a list, entering values in grid cells, and so on. You can view the methods and properties available for an object in your application by exploring this object in the Object Spy or Object Browser.

However, there can be a situation when a built-in test object does not provide the functionality you need, or your tested application uses custom controls that are not compatible with the built-in test objects. Depending on whether the target control is windowed (an individual GUI element) or windowless (a graphic object painted on the surface), to access it in your test, you can use the following approaches:

Windowed (onscreen) objects

TestComplete may fail to recognize your custom windowed control if it cannot match the control with any of the supported object classes. This happens to standard controls that have non-standard class names and to custom controls that are currently not supported by TestComplete.

To command TestComplete to recognizer your control, you can do the following:

  • Map your custom control to a supported control

    A custom control can actually be a standard control with a different class name (for example, if application developers renamed the control class in the source code) or be derived from a standard control without violating the standard control’s API. If the custom control’s API is compatible with the API of one of the supported controls, TestComplete can recognize and manipulate the custom control if you map its class name to an appropriate standard class. To learn how to do it, see Object Mapping.

  • Use native methods and properties of custom controls

    If your tested application is an Open Application, you can access native methods and properties of application objects and use them in your tests. For example, you can use them to retrieve data from an object, to change its state, to trigger specific events and so on. To learn what native methods and properties are available, explore your tested object in the Object Spy or Object Browser.

    TestComplete cannot record native methods and properties of objects, so you will have to add them to your test manually.

    Here are the examples of retrieving data from custom controls using native properties:

Windowless objects

There can be a situation when TestComplete cannot recognize either individual controls of your tested application or recognizes the entire tested application’s UI as a single graphical object. This usually happens if objects are custom-drawn by the application, for example, if they are essentially bitmap images drawn on a window. Such objects, known as windowless, cannot be recognized and manipulated using standard mechanisms. To command TestComplete to recognizer your control, you can do the following:

  • Use accessibility information

    If your tested application implements accessibility information via the Microsoft Active Accessibility (MSAA) engine or the UI Automation framework, you can configure TestComplete to retrieve that accessibility information and use it to recognize your custom controls. For example, TestComplete uses MSAA to identify objects in Microsoft Office, FoxPro, Adobe Flash and Sybase PowerBuilder applications. It uses UI Automation to recognize objects in Silverlight applications. See:

  • Recognize controls by their text contents

    If your custom controls are custom-drawn by your application, for example, if they are bitmap images drawn in a window, you can command TestComplete to recognize the text your controls render. You can also locate the needed controls on the screen by their text content. To learn more, see:

  • Interact with custom controls through COM

    If your tested application is COM-based and provides a COM interface for your custom object, you can access this COM object from your test and use its methods and properties to retrieve data from the control and change its state. For example, Microsoft Office applications have an extensive COM model that allows performing almost any GUI operations via COM. For more information on using COM objects in tests, see Working With COM Objects.

  • Manipulate custom controls through DLL functions

    If your tested application includes a DLL that provides functions for interacting with your custom object, you can call these DLL functions from your test and this way automate manipulations with objects. For more information, see Calling DLL Functions From Tests.

  • Retrieve object data via the clipboard

    To retrieve text from an object in your application, your test can simulate user actions performed to copy data to the clipboard, and then use the Sys.Clipboard property to retrieve that text. For more information on simulating user actions, see Simulating User Actions.

  • Use low-level recording and playback

    In addition to object-based recording, TestComplete supports recording of actual mouse movements, clicks and keypresses you perform in your tested application, as well as delays between them. You can use low-level mode, for example, to draw objects in graphics applications. For more information, see Testing Applications in Low-Level Mode.

See Also

Working With Application Objects and Controls
About Working With Application Objects and Controls
Object Identification

Highlight search results