The Plug-in Struct and The Two Exported Functions

// forward declaration of two functions needed by the plug-in struct
static OfxStatus pluginMain(const char *action,  const void *handle, OfxPropertySetHandle inArgs,  OfxPropertySetHandle outArgs);
static void setHostFunc(OfxHost *hostStruct);

////////////////////////////////////////////////////////////////////////////////
// the plugin struct 
static OfxPlugin pluginStruct = 
{       
  kOfxImageEffectPluginApi,
  1,
  "net.sf.openfx.OfxInvertExample",
  1,
  0,
  setHostFunc,
  pluginMain
};
   
// the mandated function to return the nth plug-in
OfxExport OfxPlugin *
OfxGetPlugin(int nth)
{
  if(nth == 0)
    return &pluginStruct;
  return 0;
}
 
// the mandated function to return the number of plug-ins in this binary
OfxExport int
OfxGetNumberOfPlugins(void)
{       
  return 1;
}

The first thing to note in this section are the two functions OfxGetPlugin and OfxGetNumberOfPlugins . These two functions are the only symbols that a plug-in must export and are there to boot strap the whole plug-in identification and definition process. Note the macro OfxExport , which should be inserted before any symbol that needs to be exported from the plug-in.

OfxGetNumberOfPlugins is the first function by a host after a binary is loaded. It returns the number of separate plug-ins contained inside the binary. In this case we have only one plug-in.

OfxGetPlugin is called once for each plug-in inside the binary, and returns an OfxPlugin struct. This struct is used to tell the host what kind of plug-in it is, it's name, versioning info and to give the host two functions to use for communications. Our function returns a pointer to the static pluginStruct . All such structs should be static to avoid memory allocation issues, otherwise they will not be deleted by the host.

In order the members of pluginStruct tell the host...

  1. the kind of plug-in it is, in this case a kOfxImageEffectPluginApi . Which happens to be an image effect plug-in,
  2. the version of the API the plug-in was written to. In this case version 1 ,
  3. the unique name of the plug-in. Used only to disambiguate the plug-in from all other plug-ins, not necessarily for human eyes,
  4. the major and minor version of the plug-in, in this case 1.0 , which allows for simplified upgrades to the plug-in,
  5. a function used to set an important data structure in the plug-in,
  6. the function which the host uses to send messages to the plug-in