Object Properties, Fields and Methods That Are Unavailable to TestComplete

Applies to TestComplete 15.63, last modified on April 10, 2024

By default, methods and properties that are accessible to TestComplete tests are shown in the Object Browser panel and in the Object Spy window. If an Open Application has been compiled with external debugger information (and launched without DisableDebugAgent), almost every method, property and field, even private, are available (for information on properties access, see Access to Properties).

However, specific methods, properties and fields can remain inaccessible to TestComplete for a variety of reasons. For different applications, these are:

Limitations applied to all applications

  1. TestComplete only has access to properties, methods and events for which it can find type information. The presence or absence of this information depend on the application type. Some applications, for instance, Java or .NET executables, include type information about their objects, methods and properties. Other applications (for instance, Delphi or C++Builder) do not contain this information and must be compiled in a special way in order for them to provide it. However, some properties may still be unavailable.

  2. TestComplete only recognizes routines that use:

    • OLE-compatible data types.
    • Object types.
    • Pointers (except untyped pointers).

    Routines are not accessible if their parameters include or they return:

    • Non-object types that are not OLE-compatible (Int64, Extended or ShortString).

      This restriction is not always applied to .NET and Java applications. If a routine in a .NET application returns a value of the Int64 type or includes a parameter of this type, TestComplete can recognize this routine. Similarly, if a routine in a Java application returns a value of the long type or includes a parameter of this type, TestComplete can recognize this routine. The same concerns properties and fields of the Int64 (.NET) and long (Java) type.
    • Arrays (except strings), pointers to pointers, untyped pointers, pointers to functions, unions (variant records in Pascal) and bit fields.

      This restriction is not fully applied to .NET and Java applications. If a routine in a .NET or Java application returns an array or uses arrays as parameters, TestComplete can recognize this routine. The same concerns properties and fields that return arrays.

    Also, TestComplete does not recognize constructors, destructors, safecall functions (safecall procedures are available), or functions that return structures (records).

  3. TestComplete reads boolean properties and fields as integers: False is 0, True is any other integer value, for example, 1 or -2. To ensure that a “boolean” is read as an OLE-Variant boolean, use VarToBool. Without the VarToBool conversion, some comparison instructions (typically in VBScript procedures) may produce incorrect results.

  4. Any method removed by the development tool’s Smart Linker since it is inaccessible.

    In the case of properties, TestComplete recognizes them by detecting their read or write methods. A property will go undetected if it:

    • Only has abstract virtual read and write methods (directly or by inheritance).

    • Is never read or written to, since its access methods were eliminated by the Smart Linker.

    If a property is detected but its write method is not (under the above rules) then the property is listed as read-only. If its read method is not detected, then the property is listed as write-only.

    Although an inherited abstract property remains abstract for TestComplete, and invisible to it, if a child class implements a read or write method for the property, that method becomes visible to TestComplete and can be called directly.

  5. By default, protected and private properties are hidden. They are not visible in the Object Browser and not available to Name Mapping, and Stores project items. To make them available, enable the Show hidden members option in the Engines - General Options dialog. For more information, see Access to Properties.

  6. Since debug information does not differentiate the Char and Byte types, the Debug Info Agent™ does not distinguish them. Char properties are always considered as Byte type. To set these properties in code numeric values should be used. For instance:

    DelphiScript

    p := Sys.Process('MyProject');
    w := p.MyForm;
    w.MyChar := 'A'; // Error !!!
    w.MyChar := 65; // Correct

    The same rule applies to the Object Browser panel and to the Object Spy Window. Trying to set MyChar with a character value will lead to an error message.

    Rather than specifying the numerical value directly, you can use the getOrd function, which returns the ordinal value for the character. For example,

    DelphiScript

    w.MyChar := getOrd('A'); // Correct

  7. Methods can use parameters that are pointers to one- or two-byte values, for instance, short int *, wchar_t * or bool * in C++, PSmallInt, PWordBool in Delphi. Debug information can report that these parameters are pointers to strings, so, by default, when calling an object’s method from a test, TestComplete will attempt to convert the specified parameter value to a string and the call will fail. To work around the problem, use the DebugAgent.TreatPCharAsVType method that specifies whether TestComplete should treat the “problematic” parameters as integer, boolean or string values.

  8. Functions can return values through a reference parameter. Usually, these are functions that fill buffers with some data: from a file, a window, memory, etc. TestComplete does not support reference parameters used to return values from functions. Examples of these parameters are lpNumberOfBytesRead in the ReadFile function or lpString in GetWindowText. If a function writes a value to a parameter passed by a reference, the value is not copied to the variable passed as a parameter and cannot be retrieved in a test. This applies to functions provided by Win32API and Utilities objects as well as application functions made accessible in Open Applications.

Limitations that are specific to .NET applications

  • The Decimal data type is supported as Double.

  • TestComplete supports indexed properties by adding the Item property to the object that contains an indexed property. Note, however, in the Object Browser you cannot specify the index value for those properties that uses a class type as a parameter. This concerns, for example, the indexed properties that use the string as an index parameter. You can get or set these properties in tests, but you cannot view them in the Object Browser. The indexed properties that use indexes of value types (int, long, bool and others) are supported both in tests and in the Object Browser.

  • TestComplete panels and dialogs (for instance, the Object Browser panel and Object Spy window) do not display property values for objects that are inherited from System.Windows.Forms.Control class and whose IsHandleCreated property returns False. Instead of property values, TestComplete displays the “Cannot get the value of this property.” string. Nevertheless, you can work with properties of these objects in your tests.

  • Extension methods are not supported.

  • TestComplete cannot get and set values of .NET object fields that hold COM Interop object references.

Limitations that are specific to Microsoft Visual C++ applications (unmanaged)

This section applies to Open Applications compiled in Visual C++ 7.0-9.x that include wrapper classes or debug information.

Wrapper class limitations:

  • To be visible, variables must be one of the following types:

    • Ordinary OLE-compatible types.

    • CObject class or descendant, and not template-generated.

    • Pointers to ordinal types (e.g. int, char, int *, char *) and pointers to Win32 or MFC structures. Also, MFC classes that are not inherited from CObject.

    Pointers to pointers are excluded.

    To be visible, methods must only use parameters and return values of the above types permitted for variables.

    Note: In addition to these supported types, there are wrappers for structures and classes which are not inherited from CObject, but are used in methods of MFC classes. These methods are also supported.
  • Overloaded routines are not supported. Overloaded routines are methods with the same names that belong to the same class, but have a different set of parameters. Overloaded operators are supported.

Debug Info Agent™ restrictions:

  • The Agent supports “ordinary” types: int, char, long, unsigned char, unsigned int, and pointers to ordinary types, structures or classes. Pointers to pointers, unions, pointers to procedures, bit fields and arrays are not supported.

    • The char * type is treated as a pointer to an unsigned char.

    • The int * type is treated as a pointer to an integer.

  • C++ virtual base classes cannot be recognized.

  • When multiple inheritances are present, some fields of base classes may be inaccessible to TestComplete. For example, suppose we have the following class hierarchy:

    C++

    class C1
    { int x;}

    class C2 : public C1
    { int x2;}

    class C3 : public C1
    { int x3;}

    class C4 : public C2, public C3
    { int x4;}

    Class C4 has two x members, one inherited from C2 and the other from C3. In the Object Browser you can only see one C4::x member and C2::x. Field C3::x is unavailable to TestComplete.

  • An ATL window object must be inherited from the CWindowImplBaseT and CMessageMap classes or from the CAxWindowT class. MFC window objects must be inherited from CWnd, otherwise TestComplete cannot obtain the pointer for these objects.

  • Debug information in DBG format cannot be used by TestComplete since it does not supply enough type information for methods and properties.

Limitations that are specific to Microsoft Visual Basic 6 Open Applications

Due to certain limitations in Visual Basic 6, user-defined methods, properties and classes of Microsoft Visual Basic Open Applications are not visible in the TestComplete Object Browser. However, even though these methods and properties are not visible in the Object Browser, they are still available through tests.

Limitations that are specific to Delphi Open Applications

  1. Delphi objects can have default properties, which are only used when the object is specified alone. When creating tests to be used with the Debug Info Agent™, do not skip default property names. Debug information does not specify which property is the default, so all properties must be named in tests.

  2. For Delphi Open Applications created with CodeGear Delphi 2009 for Win32, Debug Info Agent™ can expose methods and properties of those objects that have at least one (not inherited) method implemented.

  3. TestComplete is not able to access public, protected and private methods and properties of Delphi applications compiled with EurekaLog 7 modules. To avoid the issue, we recommend that you disable EurekaLog when compiling applications aimed for automated testing with TestComplete.

Limitations that are specific to C++Builder Open Applications

  • The Debug Info Agent™ supports “ordinary” types: int, char, long, unsigned char, unsigned int, and pointers to ordinary types, structures or classes. Pointers to pointers, unions, pointers to procedures, bit fields and arrays are not supported.

    • The char * type is always treated as pointers to an unsigned char.

    • The int * type is treated as pointers to an integer.

  • The Debug Info Agent™ does not support C++Builder Open Applications created with Borland C++Builder v. 3.0.

  • The Debug Info Agent™ does not provide access to public, protected and private properties and methods of VCL controls in 64-bit C++Builder applications. The Debug Agent category that exposes these properties and methods is unavailable for objects in such applications.

  • C++Builder objects can have default properties that are only used when the object is specified alone. When creating tests that are used with the Debug Info Agent™, do not skip default property names. Debug information does not specify which property is the default, so all properties must be named in tests.

  • The Debug Info Agent™ can only expose methods and properties of objects inherited from TObject. C++ virtual base classes are not recognized.

  • Functions with the __msfastcall and __msreturn conventions cannot be called correctly.

  • When multiple inheritances are present, some fields of base classes may be inaccessible to TestComplete. For example, suppose we have the following class hierarchy:

    C++

    class C1
    { int x;}

    class C2 : public C1
    { int x2;}

    class C3 : public C1
    { int x3;}

    class C4 : public C2, public C3
    { int x4;}

    Class C4 has two x members, one inherited from C2 and the other from C3. However, in the Object Browser you can only see one C4::x member and C2::x. Field C3::x is unavailable to TestComplete.

  • TestComplete is not able to access public, protected and private methods and properties of C++Builder applications compiled with EurekaLog 7 modules. To avoid the issue, we recommend that you disable EurekaLog when compiling applications aimed for automated testing with TestComplete.

Limitations that are specific to Qt Open Applications

  • TestComplete has access only to native Qt object properties that meet the following conditions:

    • Defined using the Q_PROPERTY macro,

    • Have standard data types, such as int, double, bool and others, or types handled by QVariant out of the box.

  • Dynamic properties defined using the setProperty method are unavailable to TestComplete.

  • Properties that have custom (user-defined) data types are unavailable.

See Also

About Open Applications
Access to Properties

Highlight search results