It would be easy to say that editor extensions extend the editing framework, and although this is true, so do custom commands, tools, edit tasks, and so on. An editor extension is similar to any other type of extension. When the editor loads its extensions, it passes an IEditor reference to each extension using the variant initializationData parameter in the IExtension::Startup routine; whereas ArcMap extensions receive an IApplication reference, as do commands and tools. Editor extensions are another way developers can plug in to the editing model and extend it. The difference between editor extensions and other editor customizations is that extensions are automatically loaded and unloaded by the application. There can be only one instance of an extension running at a time.

Editor extensions are similar to standard extensions, but they receive a reference to the Editor object instead of the Application.

Editor extensions must be registered in the ESRI Editor Extensions component category. Like standard extensions, one instance of each of the classes in this category is instantiated when ArcMap starts up.

There are two general cases where a custom editor extension is appropriate: new low-level components or state management and automatic response to events.

Low-Level Components

Editor extensions are appropriate when you have a collection of commands and/or tools that need to access some common data or functionality. For example, a custom editing application may have several editing properties, such as the snap tolerance, that several related tools rely on. More often than not, these related tools rely on functionality additionally exposed by the extension. The extension is the engine for several user interface components.

Editor extensions are beneficial for many reasons:

• They are automatically created and destroyed by the application.
• The same extension persists throughout the entire life of the application, which helps you to manage state.
• There is a standard, easy method for obtaining a reference to any extension (IEditor::FindExtension).
• And finally, each extension is handed a reference to the Editor object; from there you can access almost any part of the application.

One use of editor extensions is to tie together a number of other editor components, such as tools and commands, allowing them to share information.

Standalone components would not share many of these benefits; you would need to consider such questions as how would the component be created, how would it be shared, and how would it hook into the application? Extensions completely solve these problems.

The editing framework ships with several editing extensions of this type including the Attributes Window, the Digitizer extension, the Topology Editor extension, and the Conflict Resolution extension.

Automatic Response

Custom editor extensions can automatically respond to specific events fired within an edit session, typically for validation purposes. Such extensions would sink the IEditEvents, IEditEvents2 or IEditEvents3 outbound interfaces on the Editor object. This is by far the more common type of custom editor extension created by users. For example, a custom editor extension may automatically validate features whenever they are created or modified.

Another common use of editor extensions is to trigger some code in response to editor events.

For an example of an editor extension that performs both of these functions, see the Subtypes Snap Agent Example.

---

Back to top

See Also Extending the Editing Framework and Subtypes Snap Agent Example.