Applies to TestComplete 14.10, last modified on May 13, 2019

TestComplete can use Active Accessibility information provided by the IAccessible interface to expose windows and controls (both windowed and non-windowed) in applications.

TestComplete can work with the applications via the MSAA engine in the following modes:

  • Default mode, which was introduced in TestComplete 7.

  • Compatibility mode, which was used in TestComplete 6 and earlier.

The modes affect the way TestComplete addresses tested objects and the set of extended properties that TestComplete adds to objects.

The modes are incompatible. The tests recorded or created in the compatibility mode will not play back correctly in the new mode and vice versa. We recommend that you use the new mode to create new tests. Use the compatibility mode to run legacy tests.

Default Mode

In the default mode, TestComplete addresses objects by their type names that correspond to accessibility roles, and the accessibility names. For example, Button("OK"), MenuItem("File"), List("Color"), and so on.

After you obtained the desired object, you can call its methods and work with its properties.

In the default mode, objects are extended with a number of properties and methods that are wrappers over some IAccessible members (such as the DoDefaultAction method). In addition, TestComplete adds extended objects with specific properties and methods that let you check the control’s state and structure, for example, to get the list of combo box items, to get the control’s text, and so on. For a full list of extended properties and methods, see properties and methods added to MSAA objects.

Compatibility Mode

To enable the compatibility mode, select the Work with MSAA objects in mode compatible with TestComplete 6 and earlier box on the Open Applications | MSAA page of your project.

In the compatibility mode, TestComplete addresses objects using the MSAAObject method.

The extended members are properties and methods of the IAccessible interface. For more information on them, see the MSDN Library.


  • If the name of an extended property or method coincides with the name of a standard TestComplete property, method or action, the extended member is placed in the NativeMSAA namespace.

  • The level of access that TestComplete gains to the application’s objects depends on the tested application itself, namely, it depends on the implementation of the IAccessible interface on the application’s windows and controls. If the application does not include accessibility information, TestComplete will not be able to recognize objects in the application by using the MSAA engine.

  • Unlike other types of Open Applications, MSAA Open Applications are not marked with the glyph in the Object Browser. This is because many applications and controls (for example, standard Win32 controls) include accessibility information, so all of them can be “opened” by the MSAA engine even without compiling the application in a special way.

    If you need to make sure that your application contains “opened” elements, simply verify that the mentioned plugin is installed and enabled in TestComplete and that the class names of the desired objects are specified in the project’s MSAA Options. You could also expand the application’s process node in the Object Browser’s Object Tree and check its child nodes -- “opened” elements are displayed with the icon.

  • Due to the same reason, the IsOpen property of MSAA Open Application processes is always False.

  • Retrieving accessibility information from the application may take some time, which can slow down the test execution. To improve the performance, you can –

See Also

About Open Applications
Using Microsoft Active Accessibility
Addressing Objects in MSAA Open Applications
Properties Added to MSAA Objects
Methods Added to MSAA Objects
Limiting the Number of MSAA Child Objects

Highlight search results