The CategorySpecific property provides a location for related plugs-ins to store information common to all plug-ins within a category. You do not need to edit the CategorySpecific property unless you are developing a set of related plug-ins that store common properties to support behavior that all plug-ins in the category share.

The CategorySpecific property includes the following subproperties. The data type appears in parentheses.

• Name (String)—Specifies the category to which the plug-in belongs. Plug-ins with the same case-insensitive name belong to the same category. Code that implements category-specific functionality can inspect this field to determine the category of the plug-in.
  Note Typically, you should avoid using a value of empty string as it will match against any name.
• Settings ( <company prefix>_<category name> CategorySettings)—The specific data type of category settings defines the option properties common to plug-ins in a category.

The built-in reporting, database, and offline results plug-ins set the CategorySpecific.Name property to ResultProcessor and set the data type of the CategorySpecific.Settings property to NI_ResultProcessorCategorySettings . You must use these values for a plug-in to appear in the Result Processing dialog box. TestStand uses these default values for any plug-in you create from within the Result Processing dialog box.

The NI_ResultProcessorCategorySettings data type has two Boolean subproperties:

• CanDisplayReport —Specifies whether the Result Processing dialog box provides a checkbox for the process model plug-in instance in the Display column.
• DisplayReport —Specifies whether the report for the process model plug-in instance displays as the active report. The checkbox in the Display column of the Result Processing dialog box sets this property.If DisplayReport is false for a plug-in instance, the instance should allocate a new report for its use in the Runstate.Execution.Reports collection. If DisplayReport is true, the plug-in instance should adopt the default report for its own use by storing the value of Runstate.Execution.Reports.ActiveReport in a plug-in run-time variable in the Model Plugin-Begin entry point and use then that report. If a plug-in does not generate both controller and socket reports and DisplayReport is false, it should not allocate a report for executions in which it does not generate reports. If DisplayReport is true, it should call Execution.Reports.Remove to delete the default report in the executions for which is does not generate reports. Plugins that generate reports in separate threads should allocate a new report for each UUT/Batch in Model Plugin-UUT Start and Model Plugin-Batch Start