Many WPF (Windows Presentation Foundation) customer applications include use of non-Microsoft controls in their UI. UFT One represents these controls with the generic WpfObject test object.

In other cases, UFT One recognizes a complex control as a set of low-level controls, instead of recognizing the functional significance of the high-level control. For example, UFT One might recognize a custom WPF calendar control as several unrelated buttons and text boxes.

In these cases, the tester cannot run any methods containing logic specific to the custom control type. Nor can the tester apply any recording logic specific to this control type.

By creating a toolkit support set using WPF Add-in Extensibility, you define new test object classes to represent these custom controls. The support set gives QA engineers the ability to run, record, learn and spy on custom WPF controls.

This section includes:

Many WPF (Windows Presentation Foundation) and Silverlight customer applications include use of non-Microsoft controls in their UI. UFT One represents these controls with the generic WpfObject or SlvObject test object respectively.

In other cases, UFT One recognizes a complex control as a set of low-level controls, instead of recognizing the functional significance of the high-level control. For example, UFT One might recognize a custom WPF or Silverlight calendar control as several unrelated buttons and text boxes.

In these cases, the tester cannot run any methods containing logic specific to the custom control type. Nor can the tester apply any recording logic specific to this control type.

By creating a toolkit support set using WPF or Silverlight Add-in Extensibility, you define new test object classes to represent these custom controls. The support set gives QA engineers the ability to run, record, learn and spy on custom WPF or Silverlight controls. You must create separate toolkit support sets for WPF and Silverlight controls, and use different APIs.

This section includes: