A.: A virtual machine’s desktop displayed in a Remote Desktop window (or VMWare, or Virtual PC window) is just an image, there are no real objects within the window. To test your application on a virtual machine, you need to install TestComplete on this machine and run your tests there.

A.: This can happen when you place the mouse cursor over an item of a tree view or some other Windows control and a tool tip is displayed. The tool tip actually covers the item you are clicking. As a result, TestComplete cannot record a click since you are actually clicking on the tool tip. To work around this problem, do any of the following:

Note: Tool tips on Windows toolbar buttons do not require waiting for the tool tip to disappear; you can just click the button that displays the tool tip. The other Windows controls that have tool tips may work in the same way, or may require you to wait until the tool tip goes away like tree view controls.

A.: Yes. Recording actual delays between user actions may be desirable if you want your scripts to be executed at the same speed as they were recorded. Without delays, scripts are executed at full speed.

There are two possible ways to record delays between user actions --

• You can record a low-level procedure. In low-level recording, TestComplete only registers mouse and keyboard events, namely, mouse clicks, keyboard events, mouse movements and mouse wheel events. Also, TestComplete registers the time delay between these events. So, the delays between user actions will be reproduced correctly. However, low-level procedures are recorded in absolute coordinates. Thus, if the application under test has changed its window size, the low-level procedure may fail to reproduce the user actions.
• You can use the Real-Time Mode option (Options | Engine Options | Record). If it is enabled, TestComplete records actual time between user actions and inserts it in the script as calls to BuiltIn.Delay.

A.: Windows Vista, compared to previous Windows versions, includes an enhanced security model. This model will limit access to data in some applications. In order for TestComplete to be able to record and play back scripts over a tested application under Windows Vista, TestComplete must be launched with the same security privileges as the application under test was launched. Note that even if TestComplete and your tested application are running under the same user account, they may have different security permissions under Windows Vista.

TestComplete 5 and later includes support for recording and playing back scripts under Windows Vista. For more information on how to specify the same security privileges for TestComplete and the tested application, see TestComplete - Windows Vista Support.

A.: The Run button launches the main routine of the TestComplete project. By default, the routine called Main is the project’s main routine. For instance, if you create a new project in VBScript, it will hold the following script code:

[VBScript]

Sub Main
' Call Test
End Sub

Uncomment the line containing the Test routine call and replace the routine name Test with the name of the routine you recorded (it is Test1 by default):

[VBScript]

Sub Main
  Call Test1
End Sub

This way, you will be able to execute your recorded script by pressing the Run button.> You can also make the recorded routine the main routine - please read the “Running Tests” help topic for more information.

A.: TestComplete sets the Windows journal hook when it starts recording keyboard and mouse events. More than likely, one of your programs (maybe the print spooler service or one of applications listed below) conflicts with the journal hook. If so, you need to terminate that program before recording scripts with TestComplete.

To check whether the problem arises due to the conflict with the journal hook, download a program using the link below, unzip and launch it, click the Journal hook checkbox and see if the system behaves the same way it did when TestComplete was in recording mode:

A.: A script is a routine written in one of the supported languages - VBScript, JScript, DelphiScript, C++Script or C#Script. Scripts can call one another. So assuming your problem is that you run Script1, it stops, then you launch Script2, it ends too, then the solution is simply to modify the main script in the following way --

[VBScript]

Sub Main
  Call Script1
  Call Script2
  Call Script3
  ...
End Sub

There is also another way to run several scripts: you can switch to the Test Items page of the project editor and specify which tests to run and their order. When you command TestComplete to execute a project, TestComplete will run tests defined with the Test Items page of the project editor. By default, for each new project, TestComplete creates a new test item that launches the routine specified by the Main routine property of the Script’s project item. However you can add new test items to the projects and include or exclude them from testing. For more information see the “Specifying Execution Order for Tests” and “Test Items Edit Page” help topics.

A.: The way you do this depends on the TestComplete version you use.

In TestComplete 5 and later, by default the script that is defined as the main routine is a procedure that does not require parameters. If your main routine requires parameters, you should modify its declaration and specify the desired parameters in it. Then you can switch to the Test Items page of the project editor, create a test item that corresponds to the main routine and click the ellipsis button in the Parameters cell to specify the routine’s parameter.

You can also leave the main routine’s declaration unchanged and create a user-defined form to ask the tester for parameters. You then have to write script code that will display this form at the beginning of the test run. The script code can then check the values specified in the user form’s controls and use them for the test run.

In TestComplete 4, the script defined as the main routine, must be a procedure that does not require parameters. Otherwise, it cannot be executed by TestComplete. If your script requires parameters, you can create an empty main routine and call your script from it. However, this means you have to specify parameter values in the source code, that is, you have to modify the sources before running the script. If you do not want to modify the source code, use any of the following solutions:

• You can set up a small text file with the parameter string in it, and have the main procedure read its parameters from there.
• You can create a user-defined form to ask the tester for parameters. You can also use the InputBox or InputQuery functions that are built into TestComplete and supported by all scripting languages - VBScript, JScript, DelphiScript, C++Script and C#Script.
• You can use local variables. There are three kinds of local variables: project (or ordinary), project suite and network suite. All variables have the OLE Variant type. The corresponding Variables Edit Page provides a dialog for creating and deleting variables and changing their values. Once a variable has been created, it appears in the Code Completion window under the Project | Variables, ProjectSuite | Variables or NetworkSuite | Variables node. To call the variables in a script, use the construction Project.Variables.variable_name, ProjectSuite.Variables.variable_name or NetworkSuite.Variables.variable_name or using the VariableByName property. For instance --

[VBScript]

Sub Main
  . . .
  ExportFileTo (Project.Variables.MyExportFilePath)
  ToDeleteData = ProjectSuite.Variables.VariableByName("DeleteFlag")
  . . .
End Sub

A.: This error message means that TestComplete has found several windows whose attributes (class names, caption and index) correspond to the specified pattern. To resolve the issue, try to specify more precise search criteria. If there is only one window with this class name in your project the application under test may not free the previous instances of the window.

A.: Double-click the project in the Project Explorer panel. TestComplete will display the project editor in the Workspace panel. Click Properties at the bottom of the project editor and then choose Playback in the list on the left of the page. In the On unexpected window options group see if the Ignore unexpected window option is enabled. If it is, TestComplete ignores unexpected windows. If the Stop Execution option is checked, TestComplete stops the script execution.

The other four options in this group, Click on Focused Button, Press Esc, Press Enter and Send WM_Close, provide different ways of getting the window to close automatically. You can use all four if this does not confuse your application, or any combination that works for your windows.

You can also create an event handler for the OnUnexpectedWindow event and process unexpected windows in your own manner. Please read the “Handling Unexpected Windows” help topic for more details.

A.: Yes. Right-click the Event control node in the Project Explorer panel and select Edit from the context menu. TestComplete will show the Event Control editor in the Workspace panel. The properties are organized into two pages: Type Library and Event Handlers. Switch to the Event Handlers page and within this page, activate the Events tabbed page. This page lists the available events. Double-click the OnUnexpectedWindow event. TestComplete will show the New Routine dialog. In the dialog, specify the name of the event handling routine and the unit that will hold this routine; then press OK. TestComplete will create an event handler and display it in the Code Editor.

Refer to the “About Events and Event Handling” and “Creating a Script Routine That Handles the OnUnexpectedWindow Event” help topics for more information and code examples.

A: First of all, please make sure that the Script | Enable Script Debugging item in TestComplete menu is checked and that the breakpoints are enabled (that is, they are marked with the color red). Also, please make sure that the breakpoints are set on lines containing executable statements. Breakpoints set on declaration statements (that is, lines with variable or routine declarations) are ignored by the script debugger. The debugger also does not stop on conditional breakpoints if their condition or pass count is not met.

The script debugger is turned off if TestComplete is launched in silent mode (that is, with the /SilentMode parameter). If this is the case, please close TestComplete and launch it in the normal mode.

Note also, in order for you to be able use the script debugger, the user account that TestComplete is running under, must belong to the Debugger Users or Administrators group on your computer. You can check this in the Control Panel | User Accounts dialog. For more information on script debugger requirements, see the “Debugging Scripts in TestComplete” help topic.

In most cases, the problem is solved by installing or reinstalling Microsoft Script Debugger, which is available on Microsoft’s web site.

Please use the following address if you use Windows 98 or Me:

Use the address below if you use Windows NT 4.0, 2000, XP or Vista:

If installing the Script Debugger does not solve the problem, please check whether the Process Debug Manager library (pdm.dll) is correctly registered in the system. To do this, follow these steps:

1. Terminate the mdm.exe process via the Task Manager.
2. Select Start | Run and type regedit in the command line.
3. In the Registry Editor, locate the following key:

   HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{78A51822-51F4-11D0-8F20-00805F2CD064}\InprocServer32

   Its default value should contain the path to the pdm.dll library. Please check if the library exists at this location.

   If the path is incorrect, please find the pdm.dll library on your hard drive (usually, it is located in the <Windows>\System32 folder) and set the correct path for this library.

4. Close the Registry Editor.
5. Register the pdm.dll library in the system. You can do this, for instance, by executing the following command (assuming that the library is located in the C:\WINDOWS\System32 folder):

   regsvr32 C:\WINDOWS\System32\pdm.dll

6. Restart the computer.

In certain cases, the path to the pdm.dll library may be reset after you reboot the computer. It happens if a program that is launched at startup changes this path. You can determine the conflicting program by using the Windows System Configuration utility:

1. Select Start | Run and type msconfig in the command line.
2. In the System Configuration Utility, switch to the Startup page.
3. Disable some startup items and restart the computer.
4. Check the abovementioned registry key value. If it has been reset, specify the correct path again and repeat steps 1-3.

If this does not help, please check whether the pdm.dll library is loaded into the TestComplete process. You can do this using the Sysinternals Process Explorer utility. This utility is free and can be downloaded from the following address:

1. Launch Process Explorer.
2. Select the Find | Find Handle or Dll item in the main menu.
3. Enter pdm.dll and click Search.

If this library is loaded into the TestComplete process, you will see it in the search results.

Debugging issues may also be caused by the incorrect registration of the Machine Debug Manager (mdm.exe) component in the system. To register this component, please follow these steps:

1. Find all mdm.exe files on your computer.
2. Register each mdm.exe component by executing the following command:

   mdm.exe /regserver

3. Restart the computer.

If the problem still exists, try copying the mdm.exe file from a computer where the debugger works fine to your computer (usually, this file is located in the <Windows>\System32 folder). Register this file as described above and restart the computer.

Note: We recommend that you make a back-up copy of the mdm.file on your computer, so that you can restore it if needed.

The WeatherBug ver. 6.07 software is also known for causing debugging problems. If you have this application installed, try uninstalling it.