Use Plug-Ins

<< Click to Display Table of Contents >>

RayQC > 7.3 u2 > User Guide > Checklist Structures > Basic Checklist Properties > Steps and Actions > Element Options 

Use Plug-Ins

Conditions are one appropriate tool to add dynamic aspects to a checklist. The other tool is the open plug-in interface RayQC provides for all element types. A plug-in can read fields that are already filled, process these values and fill other fields with data. The effort involved in filling a checklist can actually be reduced significantly in this manner.

 

tip

Tip:

This section deals with the plug-in options present for element configuration within the Checklist Editor interface and the effects plug-ins have on checklist projects within the Checklist Viewer.

Please refer to the plug-ins section for further details regarding the available types of internal standard plug-ins, required files and definitions for the integration of external (custom) plug-ins, and tips on how plug-ins may be combined for advanced checklist logic implementations.

 

To Activate This Option

1.Within the Checklist Editor, scroll to the element that has to be equipped with a plug-in.
 

2.Select the element with a left-click, and open its plug-in tab from the Details pane at the right-hand side.
 
Please note that Information elements may not be extended by plug-in functions, and therefore do not have a plug-in tab within their Details pane.
 

3.Browse the plug-in list displayed within the toolbar for the desired function. Use the search field if required. Drag the desired plug-in function to the plug-in tab of the details pane displayed for the currently selected element. (As an alternative, plug-in functions may as well be dropped on an elements that is already present within the Checklist structure area in the center of the Checklist Editor interface. However, dropping a plug-in function there still requires to opening the plug-ins tab of the affected element in order to be able to define the required parameter settings of the plug-in function.)
 
Please note that every plug-in function has a defined set of valid parent elements. If a function cannot be used in combination with a specific element type, RayQC prevents users from dropping the plug-in function onto this element type. The internal plug-in documentation contains information about valid function - element type combinations. External plug-ins have to contain this information as part of their manifest file.
 
Another important fact about plug-in usage is that each element may only be combined with a maximum of 1 plug-in function. Therefore, if a user tries to drop a plug-in function on an element that already has a plug-in usage, RayQC displays a dialog, asking the user what to do: Replace the existing plug-in function for that element, or abort adding the new plug-in function relation.
 
Plug-in usage modifications may take serious effect on the logical flow of checklists. Just imagine that in scenario A a specific element converts a boolean result (e.g. by using the InvertBoolean function of the Logic plug-in), whilst this inversion is missing in scenario B: This small difference may cause conditional dependencies and references established by element result usage for function parameter definitions to be evaluated totally different, which in turn may lead to a dramatically changed evaluation flow. Well, it is highly recommended to double-check the outcome of plug-in replacement in order to prevent undesired side-effects.
 

4.As soon as a plug-in has been added to an element, RayQC displays input controls for the parameters needed to successfully execute the plug-in function.
Since each plug-in comes with an individual set of parameters, a full list cannot be provided in this section. It is highly recommended to read the plug-in section for details regarding the internal plug-ins delivered with the RayQC installer resources, and review the manifest file or contact the author of external plug-ins for a more detailed technical documentation of those plug-ins.
 

5.Now it is time to save the checklist template changes, and test them by walking through the steps of the checklist within the Checklist Viewer.
 

6.Make sure to set all element results as required to provide all parameter values and element / group availability status settings needed to make the element with the newly created plug-in available and fully prepared.
 

7.A rightwards pointing arrow icon should be available within the element checkbox displayed within the Checklist Viewer interface. Clicking that icon triggers the plug-in execution.
 

8.Make sure that the plug-in logic is executed as expected. If it seems due, prepare different parameter sets to determine successful and failing executions are covered with decent checklist reactions (e. g. error messages displayed within comment items, dynamic checklist branch availability, etc.). The result returned by the plug-in function execution is by default stored as the result of the element that hosts the plug-in function. However, due to type transitions, element options and other affecting settings, the result that is actually displayed within the Checklist Viewer interface may very well differ from the original return value of the plug-in function. This has to be kept in mind whilst testing and debugging the different function scenarios.