There is a special operator that allows you to dynamically load compiled plug-ins without registering them in the LibraryConfig section of rmxml.cfg file. The syntax is similar to that of other plug-ins. The <call "name"="Dyload Plugin"…> argument identifies the module to be dynamic. The < …"module"=… > argument defines the full path to a compiled plug-in module.
It is a good practice to avoid platform specific information in the module path, like specifying the module extension (.dll/.so/.dylib) or platform name. The operator will automatically append the correct extension if it is missing.
It is recommended to export either the GetOperation() or the GetOperationEx() function.
In case both functions are exported and additional tables (see below) contain only null values, the "regular" _Evaluate() function will be called instead of the _Evaluate(DynamicPlugin::EXTINFO&). A valid example of the ResultModule XML statement is shown below:
<datatype id="Example" inherit="Displacement" format="scalar” > <call name="DyloadPlugin" ents="Nodes" src="Displacement" module="@appdir/Plugins/DyloadPluginExample" onrecord="sqrt" answer="@datatype_value"/> </datatype> |
Starting with the 12.0-SA-110 release, additional tables can be used to exchange information with the plug-in module. There are total of eleven user-defined tables named tab1 to tab11. A valid example of additional tables usage is shown below:
<datatype id="ExampleEx" inherit="Displacement" format="scalar” > <define id="Dummy1" format="scalar" bind="nodes"/> <define id="Dummy2" format="scalar" bind="nodes"/> <call name="Constant" value="10" table="Dummy1"/> <call name="Constant" value="31" table="Dummy2"/> <call name="DyloadPlugin" ents="Nodes" src="Displacement" module="@appdir/Plugins/DyloadPluginExample" onrecord="linear" tab5="Dummy1" tab8="Dummy2" answer="@datatype_value"/> </datatype> |