AVEVA.Net 2.How to Write a CAF Addin

2.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 ensure 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).

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！