Using Non-TestStand UI Controls in a User Interface

1. TestStand User Interface (UI) Controls
2. Reasons for Not Using TestStand UI Controls
3. Replacing Manager Controls
4. Handling Events from TestStand
5. Handling Control Events
6. Summary

TestStand User Interface (UI) Controls

The TestStand User Interface (UI) Controls are a set of ActiveX controls that implement the common functionality applications need to display, execute, edit, save, and debug test sequences. These ActiveX controls greatly reduce the amount of source code a user interface application requires. The TestStand UI Controls include manager controls and visible controls. Connect visible controls to manager controls to create user interfaces. When you associate a control with a particular task, the manager updates the  enabled or disabled state, the visibility, and the content of the control based on the current state of the user interface.

Reasons for Not Using TestStand UI Controls

The TestStand UI Controls are designed to be extremely flexible and can cover many different use cases. National Instruments strongly recommends using the TestStand UI Controls whenever possible. However, you might want to use a different control for the following reasons:

• To provide a control that looks different than the TestStand UI Controls.
• To provide additional or different functionality than that which the TestStand UI Controls provide.

Since the TestStand UI Controls reduce the amount of code required in a user interface application, using other controls might cause your application to be more difficult to code. Most often the TestStand UI Controls provide the functionality you want. For example, custom commands can handle many of the customizations you require. You can also manage only smaller subsets of the user interface controls behavior using the CommandConnectionOptions constants, which you can use to specify the behavior you want the manager controls to handle and the behavior you want to handle manually. For example, use the CommandConnection_IgnoreEnable constant if you do not want the connection to enable or disable the connected control. You can change these options while a user interface runs. For example, if you want to disable the Test UUTs entry point once an execution has begun, set the CommandConnection_IgnoreEnable constant for the connection and disable the control manually so you can take advantage of the built-in functionality of the user interface controls while just adding the custom behavior.

Replacing Manager Controls

Replacing the manager controls is almost always a mistake in a user interface. Because the Application Manager control can access the TestStand Engine, the manager controls provide almost all the available functionality, including shutting down and restarting the TestStand Engine, managing all open executions and sequence files, and handling UI messages.

Handling Events from TestStand

You must register callbacks on the manager controls events, a process that varies depending on the language you use. In LabVIEW, you must create callback VIs.  In LabWindows/CVI, you must register callback functions. Other languages require specific mechanisms for handling ActiveX events. Refer to the documentation for a specific language for more information about registering callbacks in that language. The manager controls generate events based on what occurs in the application. For example, the SequenceFileView Manager control generates a SequenceFileViewMgr.SequenceChanged event whenever the application selects a new sequence. When you handle this event, you must update any controls that change. These changes might include disabling or enabling the control, making the control visible or invisible, or changing the content of the control. Manager controls provide many other events, but if none of those events satisfy your needs, you can monitor TestStand UI Messages or use polling to check on a certain property. These cases are extremely rare, so make sure you exhaust the manager controls functionality before considering these other methods.

Handling Control Events

You might also want to handle user interaction with the control, a process that depends greatly on the control and environment you use. After you create code to handle these events, you must access the TestStand Engine. In most cases, you can use the TestStand UI API to complete most functionality by accessing and executing Command objects.  However, but if you need advanced functionality the Command objects do not provide, you must access the TestStand Engine directly and use the appropriate API calls.

Summary

When the TestStand UI Controls do not provide the functionality you require, you must use your own controls and handle events from both TestStand and the controls themselves. Always ensure that the functionality you want is not possible using the user interface controls before you use your own controls because the TestStand UI Controls can save you a great deal of effort.

3 Ratings | 2.33 out of 5

 Print |  PDF

Reader Comments | Submit a comment »