Open topic with navigation
This section describes troubleshooting and limitations for developing support for custom WPF or Silverlight controls.
If you define test object operations and the corresponding custom server methods with OUT or IN/OUT parameters, the test object operation does not run correctly.
Workaround: When designing test object methods to support using WPF or Silverlight Add-in Extensibility custom servers, use only IN parameters. Instead of an OUT or IN/OUT (ref) parameter, design the operation to return a value.
UFT does not handle controls as children of your custom control if they are implemented as pop-up controls. This means that you cannot implement the IsKnownPartOf method to instruct UFT to ignore these controls and treat them as integral parts of the custom control.
UFT will recognize, spy, and learn these controls as independent controls.
You may still be able to implement recording steps on the custom control in response to events that occur on these controls, by registering event handlers to listen to events on these controls.
Relevant for Silverlight only: When the implementation of a test object method in the custom server includes an operation which blocks until the next step in the test runs, the test run session will not continue to the next step.
For example: Suppose that clicking a custom button in the application opens a modal dialog box, and your test includes the following steps:
If the implementation of the Click method in the custom server that supports MySlvButton calls (UtilityObject.ApplicationObject as UIElement).Click and that Click method does not return until the modal dialog box is closed, then the test will run the first step and never continue to the second.
Workaround: Do one of the following:
Invoke the blocking statement asynchronously using BeginInvoke.
Use mouse or keyboard operations to implement the test object method (for example, click the button using UtilityObject.MouseClick).
Relevant for Silverlight only: In some cases, when you design your support to receive Windows messages generated for controls other than the custom control you are supporting, some such Windows messages are still not passed to the custom server.
The reason for this is that during a recording session, the custom server mapped to your custom control is only created after some operation takes place on the custom control itself.
If you design the GetWndMessageFilter method to specify that your custom server will handle messages that occur on other controls, such messages can only be handled after the custom server is created.
Therefore, for example, you may have to click on the custom control before the custom server can receive and process messages generated for other controls in the application.
Depending on how you implement support for recording on your custom control, you might want to provide instructions regarding this issue to the UFT users who use your support set.