A.: Check whether the Open Application sign is displayed on the right of the desired application name in the Object Tree of the Object Browser. To verify the application during the script run, use the Process.IsOpen property. It returns True when the application is “open” and False when it is “closed”:

[VBScript]
  If MyProcessObj.IsOpen Then 
    Log.Message("The process " & MyProcessObj.ProcessName & " is open.")
  Else 
    Log.Message("The process " & MyProcessObj.ProcessName & " is a black-box.")
  End If

[JScript]  
  if (MyProcessObj.IsOpen)
    Log.Message("The process " + MyProcessObj.ProcessName + " is open.")
  else 
    Log.Message("The process " + MyProcessObj.ProcessName + " is a black-box.");

[DelphiScript]  
  if MyProcessObj.IsOpen then 
    Log.Message('The process ' + MyProcessObj.ProcessName + ' is open.')
  else 
    Log.Message('The process ' + MyProcessObj.ProcessName + ' is a black-box.');

[C++Script, C#Script]  
  if (MyProcessObj["IsOpen"])
    Log["Message"]("The process " + MyProcessObj["ProcessName"] + " is open.")
  else 
    Log["Message"]("The process " + MyProcessObj["ProcessName"] + " is a black-box.");

A.: There are two ways to get access to objects’ methods and properties of Delphi and C++Builder applications. The first is to compile the application with debugger information. The second is to use wrapper files generated by PRegister. (In both cases you have to add the tcOpenApp.pas, tcOpenAppClasses.pas and tcPublicInfo.pas units to your project).

In the first case, TestComplete works with the application through the Debug Info Agent™. The Agent uses the debug information to access published, public, protected and private methods, properties and fields of application objects. That is, almost all internal elements become available to scripts. The price for such deep access is a larger executable size (debug information increases it by several times) and slower execution speed when you call methods and properties of application objects for the first time.

If you only need access to published and public elements, you can use wrapper files rather than the Debug Info Agent™. Wrapper files free you from compiling the application with debugger information. You can use them to see and test specific elements, but not the whole application. Also, wrapper files do not slow down the script when you call methods and properties of application objects for the first time.

To expose published and public methods and properties, you need to link in a wrapper file for each unit that you want public elements to become visible, for example --

uses Windows, Classes, Buttons_p;

The wrapper files should be generated with the PRegister utility that is installed with TestComplete (you can find it in the <TestComplete>\Bin folder). For a detailed overview of wrapper files, see the “Adding Public Information to Delphi and C++Builder Open Applications” help topic.

A.: If you compiled the application in the described way, TestComplete uses the Debug Info Agent™ to access methods, properties and fields of the application objects. The Agent only sees methods that are mentioned in the debug information. If the compiler has removed a method or a property from the debugger information, this method (property) becomes unavailable to TestComplete. Typically, the compiler can remove methods (properties) that are not called in the application code. To solve the problem, call the method (property) somewhere in your code. For detailed information about “invisible” methods and properties, see the “Object Properties, Fields and Methods That Are Unavailable to TestComplete” help topic.

If you test a Delphi or C++Builder Open Application, the possible cause of the problem is that the Build with runtime packages option is enabled. If it is, disable it and then recompile the application.

A.: Yes. The application under test must be compiled as an Open Application. Then you can call the NNNObject or WaitNNNObject methods of the process or window objects. The actual name of method to be used depends on the programming language and the environment tool that you created your application with.

Application type	Direct call method name	Delayed call method name	Description
.NET Applications	WinFormsObject	WaitWinFormsObject	Provides a scripting interface to an object of a .NET application.
	VCLNETObject	WaitVCLNETObject	Provides a scripting interface to an object of a .NET application created with Borland VCL.NET library.
Visual Basic Applications	VBObject	WaitVBObject	Provides a scripting interface to an object of a Visual Basic 6.0 application.
Delphi and C++Builder Applications	VCLObject	WaitVCLObject	Provides a scripting interface to an object of a Delphi or C++Builder application created with the Visual Component Library (VCL).
	CLXObject	WaitCLXObject	Provides a scripting interface to an object of a Delphi or C++Builder application created with the Component Library for Cross Platform (CLX).
Java Applications	AWTObject	WaitAWTObject	Provides a scripting interface to an object of a Java application created with the AWT library.
	SwingObject	WaitSwingObject	Provides a scripting interface to an object of a Java application created with the Swing library.
	SWTObject	WaitSWTObject	Provides a scripting interface to an object of a Java application created with the SWT library.
	WFCObject	WaitWFCObject	Provides a scripting interface to an object of a Java application created with the WFC library (Microsoft J++).
Windows Presentation Foundation Applications	WPFObject	WaitWPFObject	Provides a scripting interface to an object of a XAML application.

Similar methods for Visual C++ do not exist, since Visual C++ objects do not have the Name property. Therefore windows and controls of Visual C++ applications are addressed in the same way as windows of black-box applications.

The sample code below illustrates the usage of the mentioned methods:

[VBScript]

Set p = Sys.Process("Project1")
' Reference to an object
Set w = p.VCLObject("Form1")
' Reference to a property
w.VCLObject("Button1").Caption = "New button caption"

[JScript]

var p, w;
p = Sys.Process("Project1");
// Reference to an object
w = p.VCLObject("Form1");
// Reference to a property
w.VCLObject("Button1").Caption = "New button caption";

[DelphiScript]

var p, w : OleVariant;
begin
  p := Sys.Process('Project1');
  // Reference to an object
  w := p.VCLObject('Form1');
  // Reference to a property
  w.VCLObject('Button1').Caption := 'New button caption';
end;

[C++Script, C#Script]

var p, w;
p = Sys["Process"]("Project1");
// Reference to an object
w = p["VCLObject"]("Form1");
// Reference to a property
w["VCLObject"]("Button1")["Caption"] = "New button caption";

Note that the method or property name may coincide with the method, property or action name used in TestComplete for this object. For example, to work with buttons, TestComplete uses the Win32Button object. It has the Click action that simulates a mouse click on the button. The application object Button may also have a Click method, for example, VCL’s TButton objects have this method. In this case you should explicitly specify which namespace to use. For instance, if the method is defined by a Visual Basic application use the NativeVisualBasic namespace to specify that you want to call a method of the application object. For information on namespaces for other languages see the “Using Namespaces” help topic.

w.VCLObject('Button1').Click // <-- call to TestComplete action

w.VCLObject('Button1').NativeDelphiObject.Click// <-- call to an application method

If your application is not an Open one or the application does not have names (as in case with the Visual C++ applications), you can assign names to the desired object using the Name Mapping panel. For instance, you can map the name Window('TMainFormClass','MainFormTitle', -1) to MyMainFrm and then work with the window using the mapped name, that is, instead of :

p.Window('TMainFormClass','MainFormTitle', -1).Click(10, 20)

You can use:

p.MyMainFrm.Click(10, 20)

For more information on mapping object names, see the “Name Mapping” help topic.

A.: The delay is caused by reading the debug info. If possible we will increase performance in this regard. If you want to only access published and public properties and methods, you can make the application “Open” using the wrapper files generated by PRegister. See the “Adding Public Information to Delphi and C++Builder Applications” help topic for more information.

A.: The way you retrieve data from a control depends on the control type. To get data from rather simple controls, you can use methods and properties provided by TestComplete. For instance, if you want to get text from an edit box, you can use the wText property of the Win32ComboBox object for Windows applications, the JComboBox object for Java applications, or the WPFComboBox object for WPF applications. To retrieve data from grid controls, you can use the wValue property of the MicrosoftDataGridView, BorlandTDBGrid or other grid objects.

If you test custom or complex controls, you can use one of the following approaches to retrieve the control’s data:

• Compile the tested application as an Open Application. Open Applications provide access to their internal objects, methods and properties. .NET, Java and Visual Basic 6.0 applications are always “open” to TestComplete. Visual C++ 6.0, Delphi and C++Builder applications need to be recompiled in a special way. More information on using the Open Application approach is below.
  Note, that even if you compile your application as an Open Application, some methods and properties may remain unavailable to TestComplete (some examples are described in the “Object Properties, Fields and Methods That Are Unavailable to TestComplete” help topic). In this case you can try using other workarounds.
• Export the created script code to the tested application making it a Self-Testing Application. Since the exported code will be located within the tested application, it will be easier for your script routines to obtain access to the desired data. To learn how to create Self-Testing application, see the “Self-Testing Applications” topic in TestComplete’s help.
• Write script code that will simulate keystrokes and mouse clicks in order to copy the desired data into the clipboard and then obtain it via the Sys.Clipboard property.
• Modify the tested application, so that it provides access to the desired data. For instance, if the application under test is COM-based, you can implement a helper COM object that will obtain the desired data and return it via a property. Another alternative is to place a button on a form that will save all values of this form’s controls to a file.
• Another way to get data from a control or window is to obtain the image of this control (or windows) and then retrieve text from it using the OCR feature.

For Open Applications there are two possible methods:

• The first is to write a public method that will retrieve all content, reformat it into a standard data type (string, array, etc) for the test script to get and check. Depending on the need, you can also create a method that will do the checking itself, and then return the results. Once the method is done, it can be inherited, and so on. You can forget you ever “fixed” your source so scripts have access to the control’s data. Note that this method is available for any kind of Open Application - Delphi, C++Builder, VC++, VB, Java or .NET.
• The second method is to explore the control in the Object Browser and find its “native” properties and methods that provide access to the control’s data. You can use these properties and methods in your scripts to obtain and process the control’s data in the needed way. Note that for Visual C++, Delphi and C++Builder Open Applications this requires you to compile your application with debug information.

To learn more about retrieving data from controls, see the “Working With Custom Controls” and “Retrieving Data From Application Objects, Windows and Controls” help topics.

A.: TestComplete 6 introduces extended support for popular grid controls: Microsoft DataGridView and DataGrid, Developer Express XtraGrid and QuantumGrid, Infragistics UltraGrid, Syncfusion Essential Grid and Borland TDBGrid. For these controls, TestComplete provides the wValue property that lets you retrieve the value of a particular grid cell:

w = Sys.Process("DataGridViewSample").WinFormsObject("MainForm").WinFormsObject("DataGridView")
val = w.wValue(5, "Product Name")

If you test a grid control other than those listed above, or if you use TestComplete 4 or 5, you can use any approach suggested above. Usually, the most effective solution is to compile the tested application as an Open Application, so that you can access grid data using internal methods and properties of the grid control. Below is the code that demonstrates how to retrieve the value of a Microsoft PropertyGrid item:

[VBScript]

Sub Main
  Dim p, Grid, SizeStr

  Set p = Sys.Process ("PropertyGridSample")
  Set Grid = p.WinFormsObject("Form1").WinFormsObject("propertyGrid1")

  SizeStr = GetValue (Grid, "Layout.Size")
  Call Log.Message ("Layout.Size: " & SizeStr)
End Sub

Function GetValue (Grid, FullLabel)
  Dim Labels, Coll, Item, i

  Labels = Split (FullLabel, ".")

  Set Coll = Grid.GetPropEntries
  For i = 0 To UBound(Labels)
    Set Item = Coll.Item_2 (Labels(i))

    If Item Is Nothing Then
      Call Log.Error ("The specified item was not found (" & FullLabel & ").")
      Exit Function
    End If

    Set Coll = Item.GridItems
  Next

  GetValue = Item.PropertyValue.ToString.OleValue
End Function

[JScript]

function Main ()
{
  var p, Grid, SizeStr;

  p = Sys.Process ("PropertyGridSample");
  Grid = p.WinFormsObject("Form1").WinFormsObject("propertyGrid1");

  SizeStr = GetValue (Grid, "Layout.Size");
  Log.Message ("Layout.Size: " + SizeStr);
}

function GetValue (Grid, FullLabel)
{
  var Labels, Coll, Item, i;

  Labels = FullLabel.split (".");

  Coll = Grid.GetPropEntries();
  for (i =0 ; i < Labels.length; i++)
  {
    Item = Coll.Item_2 (Labels[i]);

    if (Item == null)
    {
      Log.Error ("The specified item was not found (" + FullLabel + ").")
      return;
    }

    Coll = Item.GridItems;
  }

  return Item.PropertyValue.ToString().OleValue;
}

[DelphiScript]

function GetValue (Grid, FullLabel);
var nLabels, Coll, Item, i : OleVariant;
begin
  nLabels := BuiltIn.GetListCount (FullLabel, '.');

  Coll := Grid.GetPropEntries;
  for i:=0 to nLabels-1 do
  begin
    Item := Coll.Item_2 (GetListItem (FullLabel, i, '.'));

    if Item = nil then
    begin
      Log.Error ('The specified item was not found (' + FullLabel + ').');
      Exit
    end;

    Coll := Item.GridItems
  end;

  Result := Item.PropertyValue.ToString.OleValue;
end;

procedure Main;
var p, Grid, SizeStr : OleVariant;
begin
  p := Sys.Process ('PropertyGridSample');
  Grid := p.WinFormsObject('Form1').WinFormsObject('propertyGrid1');

  SizeStr := GetValue (Grid, 'Layout.Size');
  Log.Message ('Layout.Size: ' + SizeStr);
end;

[C++Script, C#Script]

function Main ()
{
  var p, Grid, SizeStr;

  p = Sys["Process"]("PropertyGridSample");
  Grid = p["WinFormsObject"]("Form1")["WinFormsObject"]("propertyGrid1");

  SizeStr = GetValue (Grid, "Layout.Size");
  Log["Message"]("Layout.Size: " + SizeStr);
}

function GetValue (Grid, FullLabel)
{
  var Labels, Coll, Item, i;

  Labels = FullLabel["split"](".");

  Coll = Grid["GetPropEntries"]();
  for (i =0 ; i < Labels["length"]; i++)
  {
    Item = Coll["Item_2"](Labels[i]);

    if (Item == null)
    {
      Log["Error"]("The specified item was not found (" + FullLabel + ").")
      return;
    }

    Coll = Item["GridItems"];
  }

  return Item["PropertyValue"]["ToString"]()["OleValue"];
}

You can find more information and code examples on working with various grid controls in the “Working With Grids” topic in TestComplete’s help. You can also download grid samples from the following pages:

A.: Yes, TestComplete can simulate user actions like mouse clicks and keystrokes on any window and control. To work with standard Win32, Java and WPF (XAML) controls, TestComplete uses special program objects like Win32ComboBox, JTree, WPFListView. TestComplete can also recognize many popular third-party grid, menu and toolbar controls, for which it provides “smart” recording and playback support. For a list of supported third-party controls, see TestComplete - Third-Party Controls.

By using the Object Mapping feature, you can configure TestComplete to handle custom controls, just like they were standard controls. It lets you set the correspondence between control types and their possible class names. This way, you will be able to work with custom controls using specific methods and properties provided by TestComplete. For instance, you will be able to select items in a custom combo box by item names, select toolbar items by position of an item on the toolbar, and so on.

To map controls, open the Properties page of the project editor and then choose Object Mapping in the list on the left of the page, click Add Class Name and enter the needed name. If the Win32 methods do not work for a control, it means that either the control does not process Windows messages properly, or the control was mapped to the wrong Win32 object.

If you need deeper access to controls from scripts, for example, you need to access “native” properties of custom controls, you should compile the tested application as an Open Application. Without this, the controls will be “closed” for TestComplete, so you will be able to test them via the UI only. For more information on how to make the application “Open”, see the “Open Applications” help topic.

A.: Yes, TestComplete 5 and later provides support for WPF (XAML) controls and applications. You can test WPF controls the same way you test Win32 or .NET controls - by simulating keystrokes and mouse clicks over them. TestComplete also provides access to private, protected and public fields, properties and methods of the controls.

To work with XAML controls, TestComplete uses special program objects - WPFMenu, WPFToolbar, WPFButton and others. They correspond to controls of the System.Windows.Controls namespace and provide specific properties and methods that let you, for example, select toolbar items by position of an item on the toolbar, and so on. Other controls are treated as window objects (that are also extended with the control’s private, protected and public fields, properties and methods exposed by TestComplete).

To address controls in WPF applications, you should use a special WPFObject method. For more information, see the “Testing WPF Applications” TestComplete help topic.

Note that the described functionality is available only if the WPF Controls Support plug-in installed and enabled. Otherwise, you are only able to test WPF (XAML) controls via the UI, as black-box application windows.

A.: Yes, TestComplete 6 provides extended support for Java controls. You can test these controls the same way you work with Win32, .NET or WPF controls, by simulating mouse clicks and keyboard input over them. Additionally, TestComplete provides access to private, protected and public fields, properties and methods of the controls.

TestComplete works with Java controls using special program objects like JTable, JMenuBar, JComboBox and others. They correspond to controls of the javax.swing package and provide specific properties and methods that let you simulate clicks on table cells, select menu items and much more. Other controls are treated as window objects (they are also extended with the control’s private, protected and public members exposed by TestComplete).

To address controls in Java Swing applications, you should use the SwingObject or WaitSwingObject methods. For more information, see the “Testing Java Applications” topic in TestComplete’s help.

Note that the described functionality is only available in TestComplete 6 if the Java Controls Support plug-in is installed and enabled. If this plug-in is not installed, you are only able to test Java controls in “black-box” mode, via the UI.

A.: If your component is not a window object, it is impossible to get access to its properties if you are performing black-box testing. In this case, there are two ways to solve the problem:

1. Compile your tested application as an Open Application. Open Application non-visual objects can be obtained through methods and properties of visual objects. That is, to get access to a non-visual object, you need to create or find a property, field or method of a visual object that will return a reference to the desired non-visual object.
2. Create an auxiliary COM object in the tested application. It will perform actions that you cannot perform using the black-box testing approach. You can refer to your COM object using Sys.OleObject.

For .Net Applications there is another possibility: If the .NET Open Applications Support plug-in is installed, you can obtain a reference to the desired object through the AppDomain(...).dotNET statement. The dotNET property lets you address methods and properties of static classes using the following notation:
Sys.Process("MyApp").AppDomain("MyApp.exe").dotNET.namespace_name.class_name.property_name.

A.: The Object Browser panel displays object properties and methods available to script routines. The Object Browser sees everything a script sees, and a script sees everything the Browser sees. For the script, you need the right syntax, for the Browser, you need to follow the tree branches and use the ellipsis ([...]) buttons. So, the Browser, used correctly, will show you all accessible properties of any object and their current values.

In scripts, you can check whether an object contains a specific property or method using the built-in IsSupported(Obj, MemberName) function. You can also enumerate through the object’s properties, fields and methods using other built-in functions like EnumProperties(Obj), EnumFields(Obj) and EnumMethods(Obj).

A.: The only way to access the text of a console window is to copy it to the clipboard using shortcuts and then work with the clipboard contents.

The following sample demonstrates how to get the complete text of a console window:

[VBcript]

Sub LogTextCMD
  Dim p, w
  Set p = Sys.Process("cmd")
  Set w = p.Window("ConsoleWindowClass", "*")
  w.Activate
  Call Sys.Keys("~ ES[Enter]")
  Call Log.Message(""Console window's contents", Sys.Clipboard)
End Sub

[JScript]

function LogTextCMD()
{
  var p, w;
  p = Sys.Process("cmd");
  w = p.Window("ConsoleWindowClass", "*");
  w.Activate();
  Sys.Keys("~ ES[Enter]");
  Log.Message("Console window's contents", Sys.Clipboard)
}

[DelphiScript]

procedure LogTextCMD;
var p, w : OleVariant;
begin
  p := Sys.Process('cmd');
  w := p.Window('ConsoleWindowClass', '*');
  w.Activate;
  Sys.Keys('~ ES[Enter]');
  Log.Message('Console window''s contents', Sys.Clipboard);
end;

[C++Script, C#Script]

function LogTextCMD()
{
  var p, w;
  p = Sys["Process"]("cmd");
  w = p["Window"]("ConsoleWindowClass", "*");
  w["Activate"]();
  Sys["Keys"]("~ ES[Enter]");
  Log["Message"]("Console window's contents", Sys["Clipboard"])
}

After you got the text, you need to parse it according to the expected text format and perform the needed checks.

A.: All windows have the window class attribute (WndClass property). For example, windows that are Win32 tree view controls can have the following class names: TreeView, TTreeView, and so on. Object mapping allows you to force TestComplete to consider different window classes as one Windows control. That is, if we have the TreeView or TTreeView class, we can refer to an object (call its methods and properties) as a standard tree view control via Object Mapping.

Here is an example that demonstrates how Object Mapping works:

1. Launch Notepad and find the following object in the Object Browser:

   Sys.Process('notepad').Window('Notepad', 'Untitled - Notepad', 1).Window('Edit', '', 1)

   You will see that the object has the wText property.
2. Right-click the project node in the Project Explorer and select Edit | Properties from the context menu. This will call the Project Properties edit page.
3. Choose Object Mapping from the list on the left of the dialog.
4. Uncheck the “Edit” class mapping for the edit control.
5. Return to the Object Browser and see the object properties of Window('Edit', '', 1). You will see that the wText property has disappeared (choose Refresh from the context menu if you do not see any changes).

This means that TestComplete does not consider windows of the “Edit” class as edit controls.

Often, applications under test include controls that implement the behavior of standard Win32 controls, but they have non-standard window classes. The purpose of the Object Mapping feature is to enable TestComplete to consider these controls as standard Win32 controls.

A.: Yes. Use the OleObject property of the Sys object. Select it in the Object Browser panel, press the Params button and specify the class ID or program ID of the desired OLE object (for example, you may type Word.Application). TestComplete will try to connect to the specified object. If the object does not exist, TestComplete will create it. Once TestComplete has connected to the object, it will display the ellipsis button in the Property value column. Press this button to see the available methods and properties.

A.: To get access to internal application elements, TestComplete requires your application to be compiled as an Open Application (see TestComplete’s help). According to the Object Model described in the help, TestComplete can access any form (or VCL TDataModule objects) and their child controls in your Open Application.

If you want to access an object that does not belong to a form, you must create a read/write property that will return this object and add this property to a form in your application, for instance, to the main form. Then, you can call this property in your script code. In a similar way you can provide access to global variables.

If you test a .NET application, you can obtain a reference to the desired object by using a static field, property or method that returns a reference to the desired object. You can access this static field, property or method using the AppDomain(...).dotNET statement. AppDomain is a method that TestComplete adds to each process initiated by a .NET application. The object returned by this method corresponds to the AppDomain object of Microsoft .NET Framework with one exception: it contains an “extra” dotNET property, which lets you address methods and properties of static classes using simple notation:

A.: It’s possible that you are testing a non-Open Application. When you test an ordinary “closed” application, TestComplete needs to know which window to address with mouse clicks and keystrokes. Some controls (for example,. TLabel and TImage in Delphi and C++Builder, or Label and Image in Visual Basic) are non-window controls. They are drawn on the canvas of the form.

To check whether the control is windowed or not, open the Object Browser. All windowed controls in it are displayed as children of the form. The non-windowed controls are not displayed.

To simulate mouse clicks over non-windowed controls, search for them using their images and perform clicks on the found area (see the “Comparing and Finding Images” help topic).

If your form implements the IAccessible interface, try using the MSAA Open Applications plug-in. It allows TestComplete to see all of the elements of IAccessible forms. After you install the plug-in into TestComplete, switch to the Object Browser panel to see if the form elements are available.

The problem with non-windowed controls completely vanishes if you compile your application as an “Open” one.

A.: It depends on the toolbar system you use. Some systems change the window index (the third parameter in the Window method), so if the toolbar window does not have a caption, TestComplete may confuse it with another window. There are two ways to be sure you press the correct button:

The first is to search for the button’s image within the toolbar window using the Regions.Find method and simulate a mouse click within the found area (see properties of the Regions object).

The second is to compile the application as an Open Application and call the Click method of the button object. Of course, this way requires the toolbar or buttons to have the Click method.

A.: The cause of the problem is that the TSpeedButton control is not a windowed one. When you examine its Enabled property, you see the Enabled property of the window that owns your SpeedButton. This is a “TestComplete” property. To solve the problem, use SpeedButton.NativeDelphiObject.Enabled. It accesses the VCL Enabled property of the control. Please see the “How TestComplete Recognizes Processes, Windows and Controls” and “Using Namespaces” help topics in TestComplete for more information.

A.: Add the TMaskEdit class to the Object Mapping / Edit section (Project editor -> Properties page -> Object Mapping section). Once you have done this, the wText property will be available for the problematic editors.

A.: A tooltip is a text string that is shown when a user pauses the mouse pointer over the control. To obtain the control’s tooltip, compile the application as an Open Application. The name of the property containing the tool tip depends on the development tool that your tested application was created with. For instance, in Visual Basic 6.0 the property is called TooltipText, in Delphi or C++Builder it is called Hint, for web page elements the property’s name is title.

If you test a black-box application, then you can try to get the tool tip text by simulating the following actions:

• Move the mouse pointer over the desired control.
• Pause the pointer over the control for some time. This will cause the control to display the tool tip.
• The tool tip is a window, so you can obtain its caption which will be the tool tip text.

The following code demonstrates how you can obtain the tool tip of a VCL control (Delphi application):

[DelphiScript]
var
  p, w, h : OleVariant;
begin
  …
  // Obtains the process
  p := Sys.Process('YourApplication');
  // Obtains the desired control
  w := p.Window('TMainForm', '*').Window('TPanel').Window('TServerPageControl').Window('TTabSheet', 'Overview').Window('TFrameOverview').Window('TPanel');
  // Pauses the mouse pointer over the control
  w.HoverMouse(w.Width / 2, w.Height / 2);
  // Obtains the tooltip window
  h := p.WaitWindow('THintWindow', '*', -1, 10000);
  // Posts the tooltip text to the log
  if h.Exists then
    Log.Message(h.WndCaption);
  …
end;