How to Write a Common Application Framework Addin

Architectural Considerations for Addins

Most addins embody at least four separate concepts:

• Specific behaviour as a Common Application Framework (CAF) Addin

• Zero or more graphical user interface controls and dialogs

• 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, Graphical User Interface (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 useable 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 initialized independently of the addin itself.

Keeping the application code, the GUI control code and the GUI management code separate is good practice. It 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 Application Programmable Interface (API) and other standard interfaces. The arrows illustrate the natural lines of communication between each component and the interfaces of the other components.

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 CAF 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 register them with the CAF WindowManager - once only. Determines whether the docked window settings are to be saved between runs of the CAF-based program.

• To manage the initialization of any GUI controls and dialogs required and add them to the docked window if appropriate.

• To initialize any associated application code (but not necessarily the application data).