3ds Max 2010 is not binary compatible with plug-ins built with earlier versions of the 3ds Max SDK. This guide describes most changes needed to upgrade a plug-in to 3ds Max 2010. Depending on what version of 3ds Max your plug-in was compiled against you should consult the appropriate what's new guide for each intermediate version of 3ds Max SDK.

The following are the major new features in 3ds Max SDK 2010 that require changes to existing plug-ins.

• Asset file management - The methods in the 3ds Max SDK that were passing file names as strings have been replaced by methods that use MaxSDK::AssetManagement::AssetUser instead. File paths representing assets should never be stored by plug-ins as strings. Plug-ins should switch to representing file assets as described in the topic Declaring and Representing Assets.

• Asset file resolution - Any code related to asset file resolution using the IPathConfigMgr and Interface classes will have to be updated to use the corresponding methods of the new class IFileResolutionManager. The various directory methods on class Interface and class IPathConfigMgr are replaced with new methods that uses MaxSDK::AssetManagement::AssetType. In IFileResolutionManager a set of methods have been exposed to manage a path caching mechanism. We have removed the xref boolean parameter that could be passed to IFileResolutionManager::GetFullFilePath(). See Asset File Path Resolution for more information.

• Asset enumeration - Code that referred to IAssetAccessor::AssetType needs to be updated to use the new enumeration MaxSDK::AssetManagement::AssetType. See Enumerating and Exposing Assets for more information.

• AutoPtr - The new policy based MaxSDK::AutoPtr has no impact on existing plug-ins except when MaxSDK::AutoPtr had ownership of an object that is not destroyed via the delete operator. In those cases, the plug-in code will need to change to use the appropriate specialization of the MaxSDK::AutoPtr class template.

• User interface updates - A number of changes to the 3ds Max user interface will have an impact on existing plug-ins. See User Interface Updates for more information.

• Window message filtering - Progress dialogs should now use the class MaxSDK::WindowsMessageFilter for filtering windows messages to avoid issues that may cause Windows WPF controls to cease functioning. For more information see Windows Message Filtering.

There have been several changes to the SDK designed to increase the stability of 3ds Max. The following is a summary of changes.

• The 3ds Max SDK now uses MCHAR instead of TCHAR and MSTR instead of TSTR. While no change is necessary to plug-in code for this version of 3ds Max, future versions of 3ds Max may deprecate TCHAR and TSTR in order to support Unicode.

• 3ds Max SDK now uses const qualifiers on arguments and return values of type MCHAR* and MSTR& where appropriate.

• RefListItem, RefList and ReferenceTarget::GetRefList() were deprecated. Also, the public data member ReferenceTarget::refs has been made private. Plug-ins should use DependentIterator to iterate through the direct dependents (ReferenceMakers) of a given ReferenceTarget instance. See the DependentIterator documentation for an example on how to iterate over the dependents of a ReferenceTarget.

• The IAssetAccessor has been modified to handle assets as MaxSDK::AssetManagement::AssetUser instances. The methods that were using strings for asset representation were deprecated. The class NameEnumCallback and the corresponding method Animatable::EnumAuxFiles() have also been deprecated. The new AssetEnumCallback class and corresponding Animatable::EnumAuxFiles() should be implemented and used by plug-ins.

• The file IAssetAccessor. h has moved from the folder maxsdk\include to maxsdk\include\assetmanagement.

• 3ds Max now enforces correct deletion of plug-in instances via pointers to class Animatable, ReferenceMaker, or ReferenceTarget; the destructor of these classes has been made protected. As a side effect, instances of these classes cannot be allocated on the stack or passed by value as function parameters. For information on how to properly deallocate these objects see the topic Reference Object Lifetime Management.

• Destructors have been made virtual in a number of base classes, making deletion of classes possible using a base class pointer.

See the reference section for a list of deprecated API elements.