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.
In the default mode, TestComplete addresses objects by their type names that correspond to accessibility roles, and the accessibility names. For example,
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.
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
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
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
IAccessibleinterface 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
IsOpenproperty 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 –
Limit the number of the child objects exposed for windows and controls that support
IAccessible. For more information on this, see Limiting the Number of MSAA Child Objects.
Expose only the objects you use in your tests. See Enhancing TestComplete Performance.
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