Known Issues - Standard Windows

The following known issues exist when testing on Standard Windows applications.

Running

The following known issues exist when running tests on Standard Windows applications:

Two application instances

In the record and run settings, you can specify an application for UFT One to open when running your test. In some cases, when you run a test, two instances of the application are opened.

Workaround: In the Windows Task Manager, find the name of the UFT One child process running the application. In the Record and Run Settings dialog box, use this process name for the application in Application details.

Exist statement

An Exist statement called after a Close operation sometimes returns True, even though the application is closed.

Cause: Performance improvements in running Standard Windows tests cause the Exist method to run even before the application finished closing.

Workaround: Add a Wait statement before the Exist step, to give the application time to close. Alternatively, call Exist in a While loop until it returns False, to make sure that the application is closed.

Back to top

Recording

The following known issues exist when recording on Standard Windows applications:

  • When recording on WinMenu objects, the Active Screen is not captured.

  • If you record using Windows logo key shortcuts, the recording may be inaccurate.

    Workaround: Use the Start menu instead of the Windows logo key when recording.

Back to top

Spying

When using the pointing hand mechanism from the Object Spy to point to MFC static text or tab controls, UFT One may fail to return the correct object.

Workaround: Add the object to the object repository. To do this, point to the object's parent window, select the parent window object in the Object Selection dialog box, click OK, and perform one of the following in the Define Object Filter dialog box:

  • Select the All object types option to add all of the objects in the parent window to the object repository.
  • Select the Selected object types option, click the Select button, and then select the specific object type(s) you want to add to the object repository.

After you add the object to the object repository, you can use the GetROProperty method to retrieve the run-time values of its properties. For example:

width = Dialog("Login").Static("Agent Name:").GetROProperty("width")
MsgBox width

Back to top

Checkpoints

The following known issues exist when recording on Standard Windows applications:

  • Checkpoints are not supported for WinComboBox objects of style Simple ComboBox.

  • You cannot insert a checkpoint on a WinMenu object.

    Workaround: Use the CheckProperty and CheckItemProperty methods to check specific property and item property values.

Back to top

Specific controls, test objects, and methods

The following known issues exist when using specific controls, test objects, and methods in Standard Windows application tests:

WinCalendar objects Changing the style of a WinCalendar (from single selection to multi-selection, for example) will cause the run session to fail.
Windowsless objects

Windowless objects developed using an API other than the MSAA API are not identified.

The description properties of a windowless control must include the acc_name property. By default, this property is not available in the list properties when you add a new test object.

Workaround: Add the acc_name property to the list of properties. To do this from the Define New Test Object Dialog Box, in the Test object details area, click the Add description properties button . In the Add Properties dialog box, click the Define new property button and add the acc_name property.

Type and SendKey methods

Keyboard combinations using uppercase letters may not work as expected.

We recommend using lower-case letters instead.

Back to top