In a similar way to feature class extensions, the COM class representing the custom feature is stored in a DLL, with the feature class being bound to the DLL via a CLSID, which is recorded in the geodatabase and the registry of the client machine.
Custom features are managed in a similar way to class extensions.
Once you have finished your custom feature code, there are two steps to deploy it.
- You must register the DLL on each client system that will access the feature class of the custom features. You should also ensure that the COM class of custom features is registered to the ESRI GeoObjects component category. If you have correctly implemented an ATL category map, this will be done automatically when the DLL is registered.
- You must configure the instance CLSID on the feature class that holds the custom features. The instance CLSID is the GUID of the COM class of custom features. This GUID can be found in your IDL or from the registry. How you set the CLSID on the feature class depends on whether you are about to create a feature class or alter an existing one.
If you are creating a new feature class, there are three options for setting the instance CLSID:
- Use a FeatureClassDescription object to automate the creation of the feature class in ArcCatalog. Description objects were discussed in the section on class extensions. You should return the appropriate GUID for the IObjectClassDescription::InstanceCLSID property.
- Call IFeatureWorkspace::CreateFeatureClass, setting up the CLSID parameter with the appropriate GUID.
- If you have created a UML model using CASE tools, use the Schema Wizard in ArcCatalog to create your feature class.
To configure an existing feature class to have custom features, call IClassSchemaEdit::AlterInstanceCLSID on the feature class. You should first obtain a schema lock to ensure no one else is using the feature class. The required code is similar to the IClassSchemaEdit::AlterClassExtensionCLSID example in the section on class extensions. Note that this code only needs to be run once, since it configures the database rather than any aspect of the client. If the feature class cannot be opened, as may be the case with a previously failed customization, call IFeatureWorkspaceSchemaEdit::AlterInstanceCLSID.
Note that you can check the instance CLSID of a feature class with IClass::CLSID, which effectively is the get property equivalent to the put of IClassSchemaEdit::AlterInstanceCLSID. Those feature classes without custom features will return the appropriate GUID, normally that of a geodatabase Feature.
See Also:
About custom featuresTree custom feature example
Custom feature versus other solutions
Making a class extension with your custom feature