.NET Customisation User Guide
.NET Customisation : How to Write a CAF Addin
How to Write a CAF Addin
Architectural Considerations for Addins
Most addins embody at least four separate concepts:
•
Specific behaviour as a CAF Addin
•
Zero or more graphical user interface controls and dialogues
•
The code specific to this application
•
The code to manage the graphical user interaction with the controls and application.
As in all coding situations there is much benefit to be gained by keeping these concepts separate and the code relating to each one self-contained, or "encapsulated" in object oriented jargon. This keeps the code for each simple, and offers maximum flexibility.
For example GUI controls can often be shared with other addins and applications. The NetGridControl is a good example of a control that can be reused in many situations. When this is the case the control code should be placed in a separate assembly (dll) from the addin and application. At the very least the control code should be in a separate class (file) from the addin code. Whether shared or not the principles of encapsulation advise having no application data specific code in the control.
Similarly if the application specific code needs to be active when the GUI itself is not displayed, for example in teletype (TTY) mode or for batch runs, then it, too, should be in a separate assembly and care will be needed to make sure it is correctly initialised independently of the addin itself.
Keeping the application code, the GUI control code and the GUI management code separate is good practice that leads to clearer and more logical code in all areas - much easier to support and maintain in the long term. Inevitably the addin, the application, the management and the controls need to communicate during operation. There is a natural hierarchical relationship between them. The following diagram shows the principal lines of communication between the components of the Addin and between the Addin and the AVEVA host program. The circles denote the interfaces that each component exposes - its own API (application programmable interface) and other standard interfaces. The arrows illustrate the natural lines of communication between each component and the interfaces of the other components.
Figure 2:1.
Writing an Addin
Occasionally there is a need for communication between these components that goes against the natural hierarchy - either upwards or across to other components on the same level. One important mechanism for doing this while maintaining logical encapsulation is by registering delegate functions to be executed on specific events. The definition of these events is part of the API exposed by the component notifying the event. The delegate (or call-back) function is part of the component that must respond to the event. This is discussed further later.
As another example of good encapsulation, Addins themselves should be self contained and dependencies between them should be avoided.
The specific responsibilities of the Addin code are as follows:
•
To respond to the PDMS or Marine host module to identify itself and to start and stop the addin - this is done by implementing the CAF IAddin interface functions.
•
To build and register the required menus and toolbars - once only normally.
•
To create any docking windows required and registers them with the CAF WindowManager - once only. Determine whether the docked window settings are to be saved between runs of the PDMS/Marine module.
•
To manage the initialisation of any GUI controls and dialogues required and add them to the docked window if appropriate.
•
To initialise any associated application code (but not necessarily the application data - see below).
1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.
AVEVA Logo