COM-based engine plugin components provide a capability for users to incorporate customer-specific nongeneric modeling into computations. An engine plugin component is a software component built using Microsoft's COM technology that is called by the application at certain predefined event times within the computation cycle. The plugin is allowed to modify the computation by adding additional considerations or modifying parameters. There are two types of COM-based engine plugins: (i) compiled code (usually a dynamic link library) and (ii) script code, not to be confused with plugin scripts. You can implement COM-based plugins in any COM-compatible programming language or scripting language, including the scripting languages, supported by the Engine Plugin Scripts.
COM-based engine plugins were developed to address the limitation of plugn scripts, at the expense of slightly increased complexity. Some of the available plugin points overlap those available using scripting plugins. As plugin points that currently use plugin scripts are rewritten to use COM-based plugins, backward compatibility will be preserved. Although the current plugin script capabilities continue to be supported, AGI recommends that, when a plugin point is available both for scripting and COM-based plugins, you use the COM-based plugin point.
Compiled code may be implemented in a variety of languages (Visual Basic, Visual C#, C++, etc.) that support COM interfaces. Compiled code executes almost as fast as the application program itself. Another advantage is that you can debug your component using a standard debugger while it is in use. Of course, any modification of the code requires recompilation before you can use it. While you can use, modify, rebuild, and reuse a C++ COM component while the application is still running, you cannot do this for COM components built using a .Net(Visual Basic and Visual C#, etc.). You can only rebuild it after the application has exited.
You can use WSH (Windows Scripting Host) to implement a COM Engine plugin using any text editor. You can implement them in a variety of languages (VBScript, JScript, Python, etc.). This presents the same advantages and inconveniences as plugin scripts. Although the script code is slower to execute than compiled code, you can edit scripts after each run. You cannot debug them, however. Often, proof-of-concepts are developed using scripts before being written in a compiled language for speed.
Many users may wish to use MATLAB to perform their computations. MATLAB is COM-aware and can be called through a COM interface. To use MATLAB in a plugin, AGI recommends that you create a Windows script component using a script language, and communicate with MATLAB through its COM object model. Samples are provided that use a VBScript component that opens up MATLAB and calls a MATLAB m-file to perform a computation. Because MATLAB is an application, not just a dynamic link library (DLL), function calls made between the plugin and MATLAB are likely to be very much slower than just using the scripting environment itself, which of course is slower than using a compiled language.Speed penalties of up to 50x over the use of the scripting environment itself have been observed.
Available COM-based plugins
For a list of COM-based plugins that includes their plugin points and a description, see STK Engine plugins.
Related topics:
- Engine Plugin Points
- Engine Plugin Site Interface
- Implementing Key Interfaces
- Building Engine Plugins
- Engine Plugin Registration
- Installing and Deploying Plugins
- Engine Plugin Use Example
- Engine Plugin Component Lifecycle
- Access Constraint Plugin Lifecycle
- Engine Plugin Parameter Data
- Engine Plugins Libraries