Debug Info Agent™ is an exclusive SmartBear technology, which provides practically the same access to the elements of Open Applications (objects, methods, properties, fields) as is supplied by the integrated debugger of the development tool used to compile the application. The Agent has access to public, protected and private elements.
Debug Info Agent™ supports Microsoft Visual C++, Borland Delphi, CodeGear Delphi, Embarcadero Delphi, Borland C++Builder, CodeGear C++Builder and Embarcadero C++Builder. The Agent also supports C++ applications created with the Qt library. Microsoft Visual Basic Open Applications cannot use the Agent, and would gain relatively little advantage from it, as almost all their elements are already exposed because they are ActiveX objects. Java, .NET and WPF Open Applications also do not use the Agent; they are “opened” by special plugins: Java Application Support and .NET Application Support.
When an Open Application created in one of the mentioned IDEs is compiled with external debug information, TestComplete will detect the presence of this information at runtime and launch the Agent as an interpreter to examine application elements, either through the Object Browser or from a script. For more details, see About Open Applications.
For instructions on implementing the Agent support in various types of applications, see the following topics:
Since there are faster ways to “open” internals of Delphi, C++Builder and Visual C++ applications, the Debug Info Agent™ support can be disabled by users. The Enable Debug Agent option of the Project Properties - Debug Agent Options page turns the Agent on or off for the current project, while the option with the same name of the Default Project Properties - Debug Agent Options dialog toggles the Agent support for any new project.
Additionally, the Debug Info Agent™ can be disabled through the application’s command-line. To do this, append
-DisableDebugAgent to the Command-line parameters value of the application in the TestedApps editor.
Using the Agent has the following specifics:
It requires a larger executable (holding the debug information).
The application consumes a larger amount of memory. This is because Debug Info Agent™ reads the debug information for every application’s element and keeps it in the memory allocated for the tested application.
The time taken by the Agent to retrieve data from the debug information depends on the size of the debug information. Large applications include a lot of debug information and the Agent may spend a lot of time retrieving data. Sometimes the Debug Info Agent™ is a slower way to look into the application under test, than what an Open Application otherwise provides. All other Open Application access methods that are compiled into the executable. The Agent is a runtime interpreter of debug information. However, the delay occurs only when the Agent reads the debug information for the first time.
Debug Info Agent™ cannot read debug information for dynamically linked modules.
Definitions of the application’s objects and their methods might be in external third-party packages (DLLs). Typically, these packages are loaded to the application at run time. In this case, TestComplete can always read debug information for the “main” module that defines the application. However, some additional actions are required to read debug information for the loaded packages.
If you are testing a Borland Delphi application compiled with Build with packages or an application that uses MFC classes and compiled with the Use MFC in a shared DLL option enabled, then before testing it, enable the TestComplete Read debug information for statically linked libraries project option. In this case, TestComplete will be able to read debug info for the loaded packages.
Some properties, methods and fields may be unavailable to TestComplete. For more information, see Object Properties, Fields and Methods That Are Unavailable to TestComplete.
By default, protected and private properties are not displayed in the Object Browser and other TestComplete panels and dialogs. Nevertheless, they are accessible from scripts. For more information on this and on how to make these properties visible, see Access to Properties.
Methods can use parameters that are pointers to some one- or two-byte values, for instance,
short int *,
wchar_t * or
bool * in C++,
PWordBool in Delphi and so on. Debug information can report that these parameters are pointers to strings, so, by default, when calling a method from script, 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 an integer, boolean or a string value.