COM Requires Specific Interfaces

team lib

An essential trait of every component and control you create is their support of specific interfaces. The interface is a contract between the client and the server that specifies the server will provide certain functionality. When the client implements the interface, it's accepting the contract and uses the functionality provided by the server. This part of the theory hasn't changed much since Microsoft first introduced COM and is unlikely to ever change.

Now, however, you're working in the managed environment-an environment that exists outside of the COM environment. We've seen throughout the book that this isolation can cause certain problems and requires you to perform certain tasks to ensure your code will work as anticipated. For example, in most cases, the common language runtime will marshal data between the two environments automatically, but at times you will have to perform this task yourself. Listing 8-3 (from Chapter 8) demonstrates how this works, as the code imports a Win32 API function and uses specific techniques to marshal data for this call. (You can find many other examples of this kind of activity throughout the book.)

The developer who writes applications that require services from a component has an advantage, in most cases, because the interfaces required to use a component or control from an application are well known and completely documented. However, what happens when you begin working with a container application? The Microsoft Management Console (MMC) is such an application. It provides no functionality on its own-the functionality resides within the MMC snap-ins ( components created especially for MMC). The MMC snap-ins enable the user , network administrator, and developer to perform a myriad of tasks using essentially the same user interface for every task. Container applications such as MMC often reduce the learning curve required to use an application. Using a container application definitely reduces developer work because the developer doesn't have to worry about the user interface-only the interfaces between the component and the container are important.

To create a component for MMC, you have to define specific interfaces and that means you have to learn what MMC expects. When you insert an MMC snap-in into MMC, the container application looks for specific interfaces in that MMC snap-in and calls the functions they contain. You can't even display a component in MMC without defining certain interfaces. In sum, your component has to implement an interface that the .NET Framework might not know about to interoperate with this container application.

You need to consider special interfaces in all kinds of circumstances. For example, a component that provides access to text in a file might have to implement the IDocument interface. Whether it does or not depends on what the container application expects to access on the component.


You can find everything you need to know to implement specialized components for many Microsoft products if you know where to look. For example, the interfaces used to create an MMC snap-in appear in the MMC- Related COM Interfaces help topic at . You'll see that the list isn't very long. You'll find a list of the basic MMC snap-in types and the required interfaces (some interfaces are optional) at . The list of required interfaces tells you what you must implement to create even a simple MMC snap-in.

The interfaces you must implement aren't always clear initially. For example, an MMC snap-in must implement the IComponent interface. It might appear simple at first, but we're not talking about the IComponent interface that comes with the .NET Framework-you must implement the IComponent interface for the unmanaged environment. Listing 14-1 shows the definition for the unmanaged IComponent interface.

Listing 14-1: Unmanaged version of the IComponent interface
start example
 /// <summary> /// This interface allows communication between MMC /// and the snap-in at the view level. /// </summary> [ComImport,   InterfaceType(ComInterfaceType.InterfaceIsIUnknown),   Guid("43136EB2-D36C-11CF-ADBC-00AA00A80033")] public interface IComponent {    void Initialize(       [MarshalAs(UnmanagedType.Interface)]Object lpConsole);    [PreserveSig()]    RESULT_VAL Notify(IntPtr lpDataObject,                MMC_NOTIFY_TYPE aevent,                Int32 arg,                Int32 param);    void Destroy(Int32 cookie);    void QueryDataObject(Int32 cookie,                          DATA_OBJECT_TYPES type,     [PreserveSig()]    RESULT_VAL GetResultViewType(Int32 cookie,                           out IntPtr ppViewType,                           out Int32 pViewOptions);    void GetDisplayInfo(ref RESULTDATAITEM ResultDataItem);    [PreserveSig()]    RESULT_VAL CompareObjects(IDataObject lpDataObjectA,                        IDataObject lpDataObjectB); } 
end example

As you can see, this interface bears little resemblance to the .NET Framework version. A look at the .NET Framework documentation shows that the managed version of IComponent exposes only one property, Site , and one event, Disposed() . We'll discuss this code more in the 'Re-creating COM Interfaces Using Managed Code' section of the chapter. For now, however, you need to realize that creating interfaces for container applications requires a certain amount of detective work in some cases.

You'll find one additional lesson in the code shown in Figure 14-1 that will be covered in this section of the chapter. Notice that the CompareObjects() method includes an additional interface (two variables that use the same interface) as input. The documentation doesn't list the interface as an essential MMC snap-in interface because Microsoft wrote the documentation with unmanaged component development in mind. The fact remains that you must implement the IDataObject interface within the MMC snap-in because the component will require the functionality the interface provides. This is an admittedly complex example, but the lesson it provides is important. The interface you implement because you can see it easily might have functions that rely on other interfaces you can't see during the initial research for the component. In summary, you might initially think that a component requires three or four interfaces and later in the project find that it requires a far greater number.

team lib

COM Programming with Microsoft .NET
COM Programming with Microsoft .NET
ISBN: 0735618755
EAN: 2147483647
Year: 2006
Pages: 140

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: