A.: .: It's quite easy --

[DelphiScript]

repeat
w := p.WaitWindow('WindowClassName', 'WindowCaption', 1, 500);
until w.VisibleOnScreen;

[VBScript]

b = False
Do Until b
w = p.WaitWindow("WindowClassName", "WindowCaption", 1, 500)
b = w.VisibleOnScreen
Loop

[JScript]

b = false
while(! b){
w = p.WaitWindow("WindowClassName", "WindowCaption", 1, 500)
b = w.VisibleOnScreen
}

[C++Script, C#Script]

b = false;
while(! b){
w = p.WaitWindow("WindowClassName", "WindowCaption", 1, 500);
b = w.VisibleOnScreen;
}

A.: TestComplete can trace exceptions only if the application under test is an Open Application. The fact is that TestComplete handles exceptions only when the script calls methods or properties of an application object. This is not possible with ordinary "closed" applications. Suppose that an exception occurs after pressing a button on a form. TestComplete will handle exception if the script simulates the button pressing with one of the following instructions:

w.Button1.Native.Click

w.Window("TButton", "Button1").Native.Click.

TestComplete will not handle the exception, if you use the following code to simulate the button pressing --

w.Window('TButton','Button1').Click
// Exception is not handled!!!

Note that Internet Explorer 6.0 from .NET Framework includes some issues, so exceptions that occur in VBScript, JScript or C++Script routines are not passed to TestComplete. The script simply stops without any error message. In this case, you can use the following code to determine the description of the error.

Here is a sample script that handles exceptions --

[DelphiScript]

procedure Test;
var
p, w: OleVariant;
begin
p := Sys.Process('Project1');
w := p.Form1;
w.Activate;
try
w.Button1.Native.Click; // We call "native" object method
except
// Posts the exception message to the test log
Log.Message(ExceptionMessage);
end;
end;

[VBScript]

Sub Test
Set p = Sys.Process("Project1")
Set w = p.Form1
On Error Resume Next
w.Button1.Native.Click ' We call "native" object method
If Err.Number > 0 Then
' Posts the exception message to the log and 
' clears the Err object
Log.Message(Err.Description)
Err.Clear
End If
End Sub

[JScript]

function Test()
{
var p, w
p = Sys.Process("Project1")
w = p.Form1
w.Activate()
try
{
w.Button1.Native.Click // We call "native" object method

}
catch(exception)
{
// Posts the exception message to the test log
Log.Message(exception.description)
}
}

[C++Script, C#Script]

function Test()
{
var p, w;
p = Sys["Process"]("Project1");
w = p["Form1"];
w["Activate"]();
try
{
w["Button1"]["Native"]["Click"](); // We call "native" object method

}
catch(exception)
{
// Posts the exception message to the test log
Log["Message"](exception["description"]);
}
}

A.: Yes, sure. The application under test must be compiled as an Open Application. This makes the application objects, methods and properties available to TestComplete. In scripts you can refer to the application objects, methods, properties or fields by their names. For instance:

[DelphiScript]

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

This feature works for Delphi, C++Builder and Visual Basic Open Applications and does not work for Visual C++ (Visual C++ objects have no Name property).

Note that 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, e.g. VCL's TButton objects have this method. In such case you should use the keyword native to specify that you want to call a method of the application object.

w.Button1.native.Click // <-- call to an application method

w.Button1.Click // <-- call to TestComplete action

If your application is not an Open one or the application has no 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 write

p.MyMainFrm.Click(10, 20)

For more information on mapping the object names, see "Name Mapping" in TestComplete on-line help.

A.: Use the Options object for this purpose. For instance, the following code changes the On Unexpected Window | Stop Execution option (the option from the Run Options group of the Options | Engine Options dialog) --

Options.Run.StopOnUnexpWindow = False

A.: You can use the following function to do this:

[DelphiScript]

function GetFocusedWindow(var FocusedWnd: OleVariant): OleVariant;
var w, i: OleVariant;
begin
  w := Sys.ActiveWindow;
  for i := 0 to w.ChildCount - 1 do
    if w.Child(i).Focused then
    begin
      FocusedWnd := w.Child(i);
      Result := True;
      Exit;
    end;
    Result := False;
end;

[VBScript]

Function GetFocusedWindow(FocusedWnd)
  Set w = Sys.ActiveWindow
  For i = 0 To w.ChildCount - 1
    If w.Child(i).Focused Then
      Set FocusedWnd = w.Child(i)
      GetFocusedWindow = True
      Exit
    End If
  Next
   GetFocusedWindow = False
End Function

[JScript]

function GetFocusedWindow(FocusedWnd)
{
  var w, i;
  w = Sys.ActiveWindow();
  for (i = 0; i < w.ChildCount; i++)
  {
    if (w.Child(i).Focused) 
    {
      FocusedWnd = w.Child(i);
      return True;
    };
  };
  return False;
}

[C++Script, C#Script]

function GetFocusedWindow(FocusedWnd)
{
  var w, i;
  w = Sys["ActiveWindow"]();
  for (i = 0; i < w["ChildCount"]; i++)
  {
    if (w["Child"](i)["Focused"]) 
    {
      FocusedWnd = w["Child"](i);
      return True;
    };
  };
  return False;
}

Here is an example of how to use the above function:

[DelphiScript] 

procedure Test;
var p, w, FocusedWindow: OleVariant;
begin
  p := Sys.Process('notepad');
  w := p.Window('Notepad', '*');
  w.Activate;
  if GetFocusedWindow(FocusedWindow) then
  begin
    ShowMessage(FocusedWindow.Name);
    ShowMessage(FocusedWindow.wText);
  end;
end;

[VBScript] 

Sub Test;
  Set p = Sys.Process("notepad")
  Set w = p.Window("Notepad", "*")  
  Call w.Activate
  If GetFocusedWindow(FocusedWindow) Then
    Call ShowMessage(FocusedWindow.Name)
    Call ShowMessage(FocusedWindow.wText)
  End IF
End

[JScript] 

function Test
{
  var p, w, FocusedWindow;
  p = Sys.Process("notepad");
  w = p.Window("Notepad", "*");
  w.Activate();
  if (GetFocusedWindow(FocusedWindow))
  {
    ShowMessage(FocusedWindow.Name);
    ShowMessage(FocusedWindow.wText);
  };
}

[C++Script, C#Script]

function Test
{
  var p, w, FocusedWindow;
  p = Sys["Process"]("notepad");
  w = p["Window"]("Notepad", "*");
  w["Activate"]();
  if (GetFocusedWindow(FocusedWindow))
  {
    ShowMessage(FocusedWindow["Name"]);
    ShowMessage(FocusedWindow["wText"]);
  };
}

A.: Yes. Use Sys.ActiveWindow.

A.: By default, a script can call routines declared within the same unit. To call scripts in another unit, the current one must be "linked" to it -

In DelphiScript projects place cursor at the beginning of the unit and add the following string:

uses Unit_Name;

If you need to link to several units, separate their names with commas, that is

uses Unit1_Name, Unit2_Name;

In VBScript projects place cursor at the beginning of the unit and add the following string:

'USEUNIT Unit_Name

Be sure you specify the apostrophe ( ' ) before USEUNIT.

To link to several units, use the following syntax:

'USEUNIT Unit1_Name
'USEUNIT Unit2_Name

In JScript, C++Script or C#Script projects place cursor at the beginning of the unit and add the following string:

//USEUNIT Unit_Name;

Be sure to specify the double slash ( // ) before USEUNIT.

You can link to several units in the following manner:

//USEUNIT Unit1_Name
//USEUNIT Unit2_Name

Note that units can refer to each other. In other words, circular references are allowed. For instance, if you need to call scripts declared in UnitA from UnitB, and to call scripts declared in UnitB from UnitA, you must add references to both units --

[VBScript] UnitA
'USEUNIT UnitB
...

UnitB
'USEUNIT UnitA
...

[DelphiScript]

UnitA
  uses UnitB;
...
 
UnitB
  uses UnitA;
...

Circular references are not allowed in JScript, C++Script and C#Script. In these languages, circular links may cause errors in jscript.dll (C++Script and C#Script are based on JScript and use this dll as well), which causes errors in TestComplete.

Back to list

Q.: I can use the same name for two procedures that are in different units, because I cannot use a prefix that would specify the unit. Is this correct?

Back to list

Q.: Is there a way to call routines defined in another project?

A.: Yes. It's possible. If you have several test projects, you may want to use the same routines from one project in other ones. The uses (or USEUNIT) clause added to a unit, lets you refer to routines defined in other units of the same project. If you need to call routines defined in a unit from another project, you should add a unit that holds these routines to your project. To do so, select Add Unit on the Units toolbar. This will bring up the standard Open File dialog where you can specify the unit to be added.

By default, both Unregister ProjectEvents and Insert ProjectEvents in new project options (Options | Engine Options | Project events) are enabled in TestComplete. This means that whenever you create a new project, TestComplete starts it with a new unit and this unit (Unit1.sxx in the project’s folder) has a form associated with it (Unit1.fxx). The form has the ProjectEvents control placed to it and the corresponding type library file (<ProjectName>.tlb) in the project’s folder. The type library makes it possible to call actual event handlers from the EventControl.ocx file, which is located in the folder TestComplete is installed to. This .tlb file is referenced by the form file. As a result, each time TestComplete loads the project, it registers this type library. Since the Unregister ProjectEvents option is on, each time TestComplete closes the project, it unregisters the project’s type library. So, if you try to use a unit in some project (project A) while this unit belongs to another project (project B) and has an associated form with the ProjectEvents control on it, TestComplete will try to process the type library to which this form refers. However, since the type library is not registered in the system (it was unregistered when closing project B), this attempt will fail and you will get the error message “Error reading ProjectEvents1.CGUID: class not registered.” This will not make the entire project A unusable. Only the events that are handled in the unreachable type library will not be handled in the way programmed in project B. If an event is handled in both projects, in project A it will be handled according to the logic implemented in this project. TestComplete’s project structure allows only one ProjectEvents control per project (that is why the .tlb file gets the name of the project, rather than of the unit/form the file is referenced by). However, sometimes it might be useful to have more than one ProjectEvents control in the same project. To do this, you can use a simple workaround: before importing a reusable unit, disable the Unregister ProjectEvents option. As a result, after TestComplete closes a project that contains the ProjectEvents control, the type library remains registered in the system and TestComplete can use it from other test projects. The entire technique is as follows: Disable the Unregister ProjectEvents option. Open the reusable unit within its original TestComplete project (project B) in order to register the project’s ProjectEvents control in the system. Close project B. Its ProjectEvents control will remain registered. Open another project (project A) and add the reusable unit to this project. Do not enable the Unregister ProjectEvents option when using project A. If the reusable unit handles the same event for both project A and project B (e.g. OnUnexpectedWindow) and this event occurs during project A’s run, TestComplete will call the corresponding handler from project A and, if the window remains unhandled, TestComplete will call the handler from project B.

If the unit includes the routines you don't want to "export", you can create a new unit by selecting New Unit on the Units toolbar, copy the needed routines to this unit and then add the new unit to the desired project. You may even create a unit "library", that is, units that hold the desired routines, and then add these units to any project you want.

Back to list

Q.: I need to compare an object in the beginning, and then compare it again at the end. How would I go about doing that?

[VBScript]

Sub SaveAndChange
TestedApps.RunAll 'You may also use Sys.LaunchApplications

Set p = Sys.WaitProcess("Project1", 10000, True)

If Not p.Exists Then
Log.Warning "Project not found."
 Exit Sub
End If

' Gets the button to be saved
' In our case the button name is Command1
Set SaveBtn = p.Form1.Command1

' Saves the buttons properties
Objects.Save SaveBtn, "OldBtn"

' Changes the object properties
SaveBtn.Caption = "New Caption"

' Compares the button properties with 
' the saved ones
If Objects.Compare(SaveBtn, "OldBtn") Then
Log.Warning "Caption was not changed."
Else
Log.Message "Caption was changed"
End If
End Sub

Back to list

Q.: Is it possible to capture an image or a screen while executing the script for later comparison?

[VBScript]

Set w = p.Window("MyWindowClass", "MyWindowCaption", 1)
w.Activate
Regions.SaveToFile w, "MyImage1"
. . .
If Not Regions.Compare(w, "MyImage1") Then
Log.Warning "The window " + w.FullName + " was changed!"
End If

Back to list

Q.: I save the object using Objects.Save and some properties, e.g. Items (TStrings type), are not saved. Is there any way to save these properties?

[DelphiScript]

procedure SaveItems(LV : OleVariant; FileName : string);
var
i, j : Integer;
s : string;
F : TextFile;
Node : OleVariant;
begin
AssignFile(F,FileName);
Rewrite(F);
try
for i := 0 to LV.Items.Count - 1 do
begin
Node := LV.Items.Item[i];
s := Node.Caption;
Log.Message(s);
Writeln(F,s);
{ If you use PRegister to prepare the Open Application, 
use the following line }
for j := 0 to Node.SubItems.Count-1 do
{ If you work through Debug Info Agent™,
the TStrings.Count property is invisible 
to TestComplete (see Debug Info Restrictions).
You have to call the read method of
the Count property directly.}
for j := 0 to Node.SubItems.GetCount-1 do
begin
{ If you use PRegister to prepare the Open Application, 
use the following line }
s := Node.SubItems.Strings.Strings[j];
{ If you work through Debug Info Agent™,
the TStrings.Strings property is invisible to TestComplete.
You have to call its read method directly.}
s := Node.SubItems.Strings.Get(j);
Writeln(F,s);
end;
Writeln(F,'');
end;
finally
CloseFile(F);
end;

// Compares two files
if not Files.Compare(FileName, 'ListViewContents.txt') then
Log.Error('ListView has changed', '', pmHighest)
else
Log.Message('OK', '', pmLower);
end;

procedure MainTest;
var
p, w: OleVariant;
begin
TestedApps.RunAll;
p := Sys.Process('Project1');
w := p.Form1;
w.Activate;
SaveItems(w.ListView1,'c:\Work\Test1.txt');
end; 

Back to list

Q.: How do I simulate a keypress from script code?

Back to list

Q.: How to create a COM object via script?

[DelphiScript]

w := Sys.GetOleObject('Word.Application'); // Creates MS Word
w.Visible := True;
w.Documents.Add; // Creates a new document
. . . 

[VBScript]

Set w = Sys.GetOleObject("Word.Application") ' Creates MS Word
w.Visible = True
w.Documents.Add ' Creates a new document
. . . 

[JScript]

w = Sys.GetOleObject("Word.Application"); // Creates MS Word
w.Visible = true;
w.Documents.Add(); // Creates a new document
. . . 

[C++Script, C#Script]

w = Sys["GetOleObject"]("Word.Application"); // Creates MS Word
w["Visible"] = true;
w["Documents"]["Add"](); // Creates a new document
. . .

Back to list