This document is archived and information here might be outdated.  Recommended version.


Other Plug-In Data Source Topics (ArcObjects .NET 10.4 SDK)

Other Plug-In Data Source Topics


In this topic

Plug-In Data Source Objects

Below, you can see the general object model for the ArcGIS plug-in data source objects.

Implementing copy, rename, and delete for plug-in data sources

You can integrate your data source with the copy, rename, and delete functionality of ArcGIS including the dragging and dropping of datasets.
To support this there are two optional interfaces that can be implemented on the plug-in dataset helper. IPlugInFileOperations is used to operate on a feature dataset or a standalone table or feature class. IPlugInFileOperationsClass operates on classes within a feature dataset. The members of the two interfaces work in the same way, the difference being that an extra class index parameter is present on the IPlugInFileOperationsClass members.
IPlugInFileOperations::Rename takes a name and also returns a name. The input name may or may not have a file extension on it. The output name must be in the form that names are passed to the data source on creation. When implementing Rename, remember to change any cached representation of the dataset name that you have in your plug-in dataset helper.
When implementing copy and paste with file- or folder-based data sources, remember that a user may paste a dataset to a location that is empty of other datasets. To allow this you should implement IPlugInWorkspaceFactoryHelper::OpenWorkspace to succeed on locations that are empty.
The rest of ArcObjects will also work with your copy/rename/delete implementation. For example, a client of your plug-in data source could call IDataset::Delete on one of your datasets.
Some developers will programmatically copy data by first calling IWorkspaceFactory::CreateWorkspace to make a workspace before copying data into it. To support this for your plug-in data source, implement IPlugInCreateWorkspace on your plug-in workspace factory. An implementation of this interface on a plug-in workspace factory helper registered by the Visual Basic 6 method will not be called.

Implementing attribute indexes for plug-in data sources

You may support the concept of attribute indexes on your plug-in data source to speed up certain queries. You can configure your plug-in data source so that the standard ArcCatalog user interface works with your data for displaying and manipulating attribute indexes.
The Add and Delete buttons are enabled if you implement IPlugInWorkspaceHelper2 on your workspace helper and return true for CanAddIndex and CanDeleteIndex. In this case you must also return false for IPlugInWorkspaceHelper2::IsReadOnly; this sets the esriWorkspacePropIsReadonly property for the workspace. This property does not indicate whether your plug-in data source supports read/write, rather that this particular workspace can be written to. In the case of adding an index, you are changing the schema of your data and will be writing the fact that the index has been created to the workspace in some way.
To support the listing of indexes in the user interface, implement IPlugInIndexInfo on your plug-in dataset helper. If there are no indexes, you should return a pointer to an empty Indexes object rather than a null pointer. To support the addition and deletion of indexes, implement IPlugInIndexManager on your plug-in dataset helper. You must implement this interface if you return true for CanAddIndex and CanDeleteIndex on IPlugInWorkspaceHelper2.
How you implement the indexes and the handling of queries is up to you; the plug-in interfaces enable integration with ArcGIS for manipulation of the indexes. This includes the rest of ArcObjects, for example, a client of your plug-in data source could call IClass::Indexes to get the list of indexes on your class.

Implementing license handling for plug-in data sources

If your plug-in data source will require a license to use, you must implement a plug-in extension class and also IPlugInLicense on either the plug-in workspace helper or the plug-in dataset helper.
The plug-in extension class must implement IExtension and register itself in the ESRI Mx Extensions (for drawing) and ESRI Gx Extensions (for browsing) component categories. The class may implement IExtensionConfig, in which case it will appear in the extensions dialog box. It should also implement IAutoExtension if it automatically enables and disables.
A plug-in workspace helper should implement IPlugInLicense if enabling the license enables all datasets of the data source type. If only some datasets are to be enabled, the interface should be implemented on the plug-in dataset helper. If the interface is implemented on both classes, the implementation on the dataset helper will be used. The license is checked when feature classes, tables, and cursors from data sources are created.

Enabling ArcCatalog searches with plug-in data sources

The search tools in ArcCatalog enable the user to search for types of datasets. Ideally, a plug-in data source should include a plug-in native type coclass for each type of dataset supported by the data source. As an example, if a data source supports both tables and feature classes (like shapefiles), it should have two native type coclasses; one might be called PlugInTableNativeType and the other called PlugInFeatureClassNativeType.
A plug-in native type class must implement the INativeType interface and register in the ESRI Native Types component category. Your implementation of IPlugInWorkspaceHelper::NativeType should return the appropriate native type object for each dataset type.
The native type classes are not essential. However, if you do not implement them, the search tools in ArcCatalog will not be able to search specifically for datasets of your data source.

Custom context menus and plug-in data sources

You may want to add your own commands to the context menus of your plug-in data source. For example you could provide a command to export your data to another nonstandard format.
There are four relevant component categories, but these are shared between all plug-in data sources:
  • ESRI GX Read-only Feature Class Context Menu Commands
  • ESRI GX Read-only Standalone Feature Class Context Menu Commands
  • ESRI GX Read-only Table Context Menu Commands
  • ESRI GX Read-only Feature Dataset Context Menu Commands
If you add commands to these component categories, they will appear on the context menus of all plug-in data sources, thus your solution may not integrate with that of a third party.
An alternative approach is to implement your own ArcCatalog objects for your plug-in data source, in particular a GxObjectFactory and a GxObject. This enables you to provide custom context menus that apply just to datasets of your type and also custom icons. For this solution, do not register the plug-in workspace factory to ESRI Gx Enabled Workspace Factories. For more information about how to implement ArcCatalog objects, see Adapting the Catalog.

Improving browse performance in ArcCatalog for plug-in data sources

To improve browsing performance and memory usage, ArcCatalog caches information about what file extensions are claimed by data sources. This information is used to activate data sources only when data for them is found. It is used to determine what files will be passed to the workspace factory to claim. This speeds up the process of claiming files. To support this, workspace factories may implement the optional interface IWorkspaceFactoryFileExtensions.
IWorkspaceFactoryFileExtensions has two methods; the first returns activation extensions. The workspace factory will be loaded when any of these extensions are found. The second method returns relevant extensions; these are all the extensions that will be passed to the workspace factory to claim. If the interface is not implemented, the activation and relevant extensions will both be "*", which matches everything. Extensions are listed in a string, separated by the vertical bar, '|'. As an example, a data source that implemented the shapefile format might return "shp|dbf" for the activation extensions, and "shp|shx|sbn|dbf|prj|xml" for the relevant extensions. Before testing your implementation, you may need to delete the existing cache file (GxDBFactCache.dat, normally in <your user profile>\Application Data\ESRI\ArcCatalog folder) for there to be any changes from your previous implementation. IWorkspaceFileFactoryExtensions may only be implemented on plug-in workspace factories implemented by aggregation. An implementation of this interface on a plug-in workspace factory helper registered by the Visual Basic 6 method will not be called.

Programmatically accessing plug-in data sources

One of the advantages of plug-in data sources is that once implemented, they can be accessed by client developers using the normal geodatabase ArcObjects API. You only need to use the interfaces with names starting 'IPlugIn' when implementing the data source. One problem you may encounter is when your plug-in workspace factory was implemented with the Visual Basic 6 registration method rather than the aggregation method. In this case you will not have any type library information for the workspace factory, so you will have to use late binding to create the object via its ProgID. You can find the ProgID of your workspace factory by using the Component Category Manager tool to inspect the ESRI Workspace Factories category. For Visual C++ clients there is no problem since you can just use the CLSID you returned in IPlugInWorkspaceFactoryHelper::WorkspaceFactoryTypeID to directly cocreate the workspace factory. The code below adds a SimplePoint dataset as a layer to ArcMap.
You can also open the workspace with IWorkspaceFactory::Open. In this case supply a property set with a single property, DATABASE, having the appropriate workspace string. Another way of opening the workspace is to use a WorkspaceName object; set the WorkspaceFactoryProgID and PathName properties, then call IName::Open.


See Also:

About Plug-In Data Sources
Simple Point Plug-In Data Source Example