Bundling Several Handlers in One Library File (.DLL/SO)

If you are writing a self-installing plug-in, chances are you are already providing one file which contains several plug-in items (see Self-Installing Plug-ins for more information). However, if you cannot make your plug-in self-installing, or if you prefer not to, you can still provide several items in one file.

For example, you may decide to create a toolbar with buttons linked to several custom commands and you want to provide them all in the same library file. Or you may want to provide a single file containing a custom operator and a command that applies it to the selected object.

Important

Do not mix self-installing and v1.0 plug-ins inside the same implementation file. Since you can package both types of plug-ins together in an xsiaddon file, you can easily deploy tools that contain a mixture of the two, provided that:

Each plug-in module contains only self-installing plug-in items.
Each v1.0 (non-self-installing) plug-in implementation file contains only v1.0-compliant implementation (for example, the XSIOnCommandCPP callback, instead of the MyCustomCommand_Init and MyCustomCommand_Execute callbacks).

How to Provide Several Different Types of Customization

Each customizable item, such as custom operators, custom commands and custom events, use different callbacks. For example, you use the XSIOnCommandCPP callback to implement custom commands and XSIOnEventCPP for custom events, while custom operators use Update, Init, and Term functions which take a reference to the context as an entry point in addition to any additional input and output arguments.

If you are providing one of each type of element in a file, Softimage already differentiates between them based on the callbacks used. However, if you are using more than one type (for example, two commands and one operator) in a single file, you need to explicitly differentiate between them.

How to Differentiate between the Same Type of Customization

Since the name of the command or event is always passed into the callback function, you can use a switching mechanism in the main callback which checks the name and then calls the appropriate function.

For example, to manage several events in one file, you can use a structure like this:

/* ====================================================================
	Main event callback
*/
XSI::Status XSIOnEventCPP( long in_eventID, XSI::CValueArray& in_args )
{
	switch (in_eventID)
	{
		case OnBeginSceneOpen:
			HandleOpenScene( in_args );
			break;
		case OnBeginSceneNew:
			HandleNewScene( in_args );
			break;
		...
	};
	return CStatus::OK;
}


/* --------------------------------------------------------------------
	Handler for OnBeginSceneOpen
*/
XSI::Status HandleOpenScene( XSI::CValueArray& in_args )
{
	// Handler implementation
	...
}


/* --------------------------------------------------------------------
	Handler for OnBeginSceneOpen
*/
XSI::Status HandleNewScene( XSI::CValueArray& in_args )
{
	// Handler implementation
	...
}

Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License