Cooperating with Other Extensions

Extensions that you distribute to customers might be installed alongside extensions developed by other programmers. Therefore, it is useful to design your extensions to cooperate with other extensions. Cooperation among extensions is important because the order in which extensions are listed in the EXCHNG.INI file or the registry determines the order in which extensions are called to respond to context changes in Microsoft Exchange. Extensions are called sequentially; extensions that are not designed to cooperate can block the execution of other extensions.

For example, suppose a user double clicks on a folder to display its messages. When this happens, Microsoft Exchange will call each extension to determine if it wants to participate in the event. If a extension handles the event without being selective about the context in which it has been installed, it will block the execution of other extensions that fall after it in the calling sequence. One of these other extensions might be programmed specifically to handle that event, but it will not be given a chance.

To avoid blocking other extensions, your extension should be highly selective in determining when it runs. When Microsoft Exchange passes your extension a pointer to the IExchExtCallback : IUnknown interface, your extension should use the methods of this interface to thoroughly examine the current context. An extension should run only if it determines that the current context is specific to it — for example, if the current selection is a custom message type understood only by your extension.

To avoid collisions, consider the following guidelines:

• Avoid programming extensions that provide broad or general behavior for features such as the advanced criteria dialog box that can only have one active extension. Most extensions should operate only in contexts that can be considered extension-specific.
• Extensions that are selective and highly context-specific should be registered at the beginning of the [Extensions] section of the .INI file. Those that exhibit more general behavior should be entered at the end of the [Extensions] section. For example, the standard Microsoft Exchange extension that handles the advanced criteria dialog box always returns S_OK to the IExchExtAdvancedCriteria::InstallAdvancedCriteria method. More selective advanced criteria dialog boxes must come before this entry or they will never be called.

Extensions can selectively install themselves in different contexts in the Exchange client, such as: EECONTEXT_TASK and EECONTEXT_VIEWER. By installing in a particular context, the extension needs to instantiate a new set of interface objects, such as IExchExtCommands, to handle the methods in that particular object. For example, if an extension is installed into EECONTEXT_VIEWER and EECONTEXT_SENDNOTEMESSAGE, it needs to remember which commands it has installed into which context so that it can respond to the IExchExtCommands::DoCommand method.