RayQC knows four basic types of checklist elements:
Information
•Designed to display info text and help files as additional support for users who evaluate the checklist
•Do not require result feedback during evaluation
•Do not directly affect the overall checklist result
•May not be used as trigger elements for plug-in execution
•May contain conditions, but are not usable as criterion for conditional statements themselves (i. e. they can be displayed dynamically based on the results of other elements, but cannot be decisive for the availability of other elements or groups)
Data Field
•Designed to gather textual evaluation results
•Require a string as check result
•Do not directly affect the overall checklist result, but usually have to be filled with a result in order to allow a checklist to switch from NOT FINISHED to a final PASSED or FAILED status.
•May be used as both: trigger elements for plug-in execution and target containers for plug-in execution return values
•May contain conditions, but are not usable as criterion for conditional statements themselves (i. e. they can be displayed dynamically based on the results of other elements, but cannot be decisive for the availability of other elements or groups)
Checkpoint
•Designed to gather exact result states
•Demand a boolean Yes / No check result, usually with a predefined setting regarding the expected (correct) evaluation result
•Have direct decisive influence on the overall checklist result (PASSED or FAILED)
•May be used as both: trigger elements for plug-in execution and target containers for plug-in execution return values
•May contain conditions, and are usable as criterion for conditional statements themselves (i. e. they can be displayed dynamically based on the results of other elements, and can also be decisive for the availability of other elements or groups)
Multi-Option
•Designed to gather exact result values, mainly for checklist branch availability control and the collection of meta-data
•Allow to select the actual result from a set of predefined options (1 of n)
•Do not directly affect the overall checklist result, but have to be filled with a result in order to allow a checklist to switch from NOT FINISHED to a final PASSED or FAILED status.
•May be used as both: trigger elements for plug-in execution and target containers for plug-in execution return values
•May contain conditions, and are usable as criterion for conditional statements themselves (i. e. they can be displayed dynamically based on the results of other elements, and can also be decisive for the availability of other elements or groups)
These RayQC checklist element types are equipped with differing sets of options and methods. Just to name one: Conditions may only be defined based upon the result of Checkpoint and Multi-Option elements. Therefore, any checklist without at least one of those element types is strictly unconditional and has an always identical straight forward evaluation path.
Please read the following sections for in-depth information regarding the element types and their individual specifications.