If the XSISDK_ROOT environment variable is not set, you'll get an error message that looks like this:
Cannot find include file: <xsi_application.h>
c:\users\sblair\My Workgroup\Addons\Test\src\TestCommand.cpp(7) : fatal error C1083: Cannot open include file: 'xsi_application.h': No such file or directory
If a plug-in is loaded in Softimage, then the compiler will not be able to delete the existing dll, and you will get this error when you try to rebuild the plug-in:
MyCommand : error PRJ0008 : Could not delete file 'c:\users\sblair\My Workgroup\Application\Plugins\Debug\MyCommand.dll'.
Cannot open compiler intermediate file
You can get this error after you start Visual C++ from a Softimage command prompt, exit Softimage, and then try to rebuild the plug-in.
c1xx : fatal error C1083: Cannot open compiler intermediate file: 'C:\DOCUME~1\tamu\LOCALS~1\Temp\XSI_Temp_3092\_CL_aaa02860ex': No such file or directory
When Softimage starts up, it changes the value of the TMP and TEMP environment variables. These changes are inherited by Visual C++ when you start it from a Softimage command prompt that was opened from the Plug-in Manager. But if you exit Softimage, Softimage removes the temporary folders it created, leaving the TMP and TEMP environment variables pointing to non-existent folders.
To increase compiler speed the C++ API header files often uses forward declaration, which can lead to this error if you don't include the header files for all the objects you want to use.
error C2027: use of undefined type 'Project'
c:\Softimage\Softimage_2012\xsisdk\include\xsi_application.h(30) :
see declaration of 'Project'
error C2079: 'ppg' uses undefined class 'XSI::PPGLayout'
error C2664: 'XSI::CustomOperator::AddIOPort' : cannot convert parameter 1 from 'XSI::Primitive' to 'const XSI::CRef &' Reason: cannot convert from 'XSI::Primitive' to 'const XSI::CRef' Source or target has incomplete type
error C2679: binary '=' : no operator found which takes a right-hand operand of type 'XSI::Model' (or there is no acceptable conversion)
Make sure you have included all necessary header files. Because of the naming convention of the header files it is easy to predict what header file contains each header.
For example, this table offers suggestions for solving the above sample errors:
CValue is the generalized data type that can store many types of data, including Softimage objects, which means that code that is being ported from scripting or which is generated by the cmdstubs utility will often use CValue to represent arguments.
void DoSomething( const CValue & in_XSIRef ) { //... stuff happens... }
Now suppose you want to pass a Softimage object to this function, for example a X3DObject:
X3DObject someObj ; // Won't compile: DoSomething( someObj ) ;
error C2664: 'DoSomething' : cannot convert parameter 1 from 'XSI::X3DObject' to 'const XSI::CValue &'Reason: No constructor could take the source type, or constructor overload resolution was ambiguous
A CValue takes a CRef as its representation of a Softimage object. All Softimage objects can be represented as a CRef, but they don't directly derive from CRef so they aren't truly CRef objects. However you can easily turn a Softimage object into a CRef by using the cast operator or the CBase::GetRef () function. Furthermore, you can turn a CRef into a CValue using the constructor or assignment operator. Put these two operations together and you can build a CValue out of an X3DObject.
In fact it is the fact that there are several ways to convert a Softimage object into a CValue that causes the compiler to complain, so the solution is to give the compiler some hint about exactly how it should turn the X3DObject into a CRef:
DoSomething( CValue( someObj ) ) ;
DoSomething( someObj.GetRef() ) ;
DoSomething( (CRef&)someObj ) ;
To be really explicit you could use temporary variables. This shows what functions and constructors really get called:
// This is just one of several options CRef& ref = someObj.GetRef() ; CValue val( ref ) ; DoSomething( val ) ;
Alternatively you could consider changing the function to be more specific about what type of object you expect, CValue is very vague:
If the function only works for X3DObjects then that should be clear from the signature:
void DoSomething( const X3DObject & in_XSIRef ) { //... stuff happens... }
Or if the function works with any Softimage object you might want to use CBase or SIObject:
void DoSomething( const SIObject & in_XSIRef ) { //... stuff happens... }
The conversions between CValue, CRef, CBase are very fast and CRef and CBase are lightweight objects, so it is unlikely that you will have a big performance problem in normal circumstances. However within a tight loop or other performance critical bit of code it may be preferable to use explicit types instead of CValue.
Any linker error that refers to an unresolved symbol in the C++ API is probably caused by not linking to sicppsdk.lib (or an old version):
error LNK2001: unresolved external symbol "__declspec(dllimport) public: class XSI::CRefArray __thiscall XSI::Operator::GetInputPorts(void)const " (__imp_?GetInputPorts@Operator@XSI@@QBE?AVCRefArray@2@XZ) error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall XSI::MATH::CRotation::~CRotation(void)" (__imp_??1CRotation@MATH@XSI@@QAE@XZ)
Similarily, if there is an unresolved external symbol related to a missing constant then it is probably caused by not linking to sicoresdk.lib (or an old version):
error LNK2001: unresolved external symbol "__declspec(dllimport) unsigned short const * const XSI::siControlCombo" (__imp_?siControlCombo@XSI@@3PBGB)
Module machine type 'x86' conflicts with target machine type 'x64'
By default, .Net 2005 compiles in 64 bit, so if you are working in a 32-bit environment, the linker will generate an error (Linker Tools Error LNK1112):
fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64 '<user_home>\Application\Plugins\Debugx64\TestComponentSelection.obj