TYPE_POINT | a Win32 POINT struct |
TYPE_TSTR | a 3ds Max SDK TSTR class |
TYPE_IOBJECT | a new FnPub system IObject |
TYPE_INTERFACE | a FPInterface |
TYPE_HWND | a Win32 HWND handle |
TYPE_NAME | a variant of TYPE_STRING, meant to be interpreted as an interned symbol orname in the client (eg, MAXScript represents these Name instances, as in #foo, etc.) |
All the new base types are passed naturally as pointers, so there are \_BV
and \_BR
variants for all of them (except for TYPE_HWND
). There are also \_TAB
, \_TAB_BR
, \_TAB_BV
variants for them all. For reference, all the currently available types are in the ParamType2 enumeration in /include
/iparmb2.h. Some base types are naturally passed by value, others by pointer. Basically, all the int and float-derived types are passed naturally by-value and all the rest by pointer. The by-value base types are:
TYPE_INT
TYPE_BOOL
TYPE_TIMEVALUE,
TYPE_RADIOBTN_INDEX
TYPE_INDEX
TYPE_FLOAT
TYPE_ANGLE
TYPE_PCNT_FRAC
TYPE_WORLD
TYPE_COLOR_CHANNEL
The FPValue
class has a union containing fields for all the base and table types and show the natural passing mode for each. Note that the \_BP
by-pointer variants of the base types are passed as iptr & fptr pointer fields in the PValue
union. For the types that are passed naturally by pointer, the \_BV
variants cause local copies to be made and owned by the FPValue
carrying them. The FPValue
destructor will free memory taken by these copies. Also, the \_BR
variants of naturally-pointer types need to supplied as pointers to the FPValue
(or FPParams
) constructors and are dereferenced at parameter delivery time. So, for example, the following FPInterface
method:
Tab<int> Foo(INode* object, Tab<Point3*>& points);
would be declared in the FUNCTION_MAP
as
FN_2(my_foo, TYPE_INT_TAB_BV, Foo, TYPE_INODE, TYPE_POINT3_TAB_BR);
and in the descriptor constructor as
my_foo, _T("foo"), 0, TYPE_INT_TAB_BV, 0, 2,
_T("object"), 0, TYPE_INODE,
_T("points"), 0, TYPE_POINT3_TAB_BR,