Click here to Skip to main content
15,879,239 members
Articles / Desktop Programming / MFC
Article

COM Connection Points

Rate me:
Please Sign up or sign in to vote.
4.84/5 (74 votes)
21 Jan 20035 min read 277.1K   4.4K   120   42
This article is intended to explain the concept behind connection points with a clear practical example, which will demonstrate an in-process COM server and an MFC client that uses the server.

Introduction

This article is intended to explain the concept behind connection points with a clear practical example, which will demonstrate an in-process COM server and an MFC client that uses the server.

What Exactly Is It?

It is a method used by a COM object to call back to the client. In other words, clients get call back notification from the COM object.

Perhaps you have heard about callback functions. Well, it goes like this. Suppose you have a COM object that exposes an interface IArithematic, and has a resource intensive method, say Add(int a,int b) - ("Anything for simplicity," as the hermit said when he took up residence naked in an Himalayan cave. Sam Weller—Pickwick Papers). Imagine that this method is going to take a lot of time and you do not want to wait until that task is finished. You can use that time for something. So here is where a connection point comes in. You assign a function ExecutionOver(int Result) in your client code, which the COM object can call after it has finished executing the Add method.

So, when the COM object is finished with the task, it calls the client function ExecutionOver (passing the result of addition). The client happily pops up the result in a message box. That's the whole gist. We shall go into the details now.

Image 1

How Does the COM Object Know How to Call ExecutionOver??

Imagine that the client exposes an interface ISink, which has a method

ExecutionOver(int result)
. Now, if the client can pass this interface to the COM object, the COM object can happily call ExecutionOver. For example, in the COM the code fragment may look like this:

//===================================================
ISink *pClientSink;
//(Client somehow passes the ISink interface pointer
//we shall see how later -- so pClientSink is loaded now
HRESULT Add(int a , int b)
{
  pClientSink->ExecutionOver(a+b);
}
//=====================================================

This is what really happens. The rest is for making this whole thing generic enough. Microsoft has implemented this by defining connectable objects. Let's start by examining the COM interfaces involved in connections - IConnectionPoint and IConnectionPointContainer. The object (rather than the client) implements both these interfaces.

Both the interfaces are shown below.

interface IConnectionPointContainer : IUnknown {
  HRESULT EnumConnectionPoints(
    IEnumConnectionPoints **ppEnum) = 0;
  HRESULT FindConnectionPoint(REFIID riid,
    IConnectionPoint **ppCP) = 0;
};

interface IConnectionPoint : IUnknown {
  HRESULT GetConnectionInterface(IID *pIID) = 0;
  HRESULT GetConnectionPointContainer(
    IConnectionPointContainer **ppCPC) = 0;
  HRESULT Advise(IUnknown *pUnk, DWORD *pdwCookie) = 0;
  HRESULT Unadvise(DWORD dwCookie) = 0;
  HRESULT EnumConnections(IEnumConnections **ppEnum) = 0;
};

Now, let's go one step at a time and see how the whole thing works.

A COM client calls CoCreateInstance to create the COM object. Once the client has an initial interface, the client can ask the object whether it supports any outgoing interfaces by calling QueryInterface for IConnectionPointContainer. If the object answers "yes" by handing back a valid pointer, the client knows it can attempt to establish a connection.

Once the client knows the object supports outgoing interfaces (in other words, is capable of calling back to the client), the client can ask for a specific outgoing interface by calling IConnectionPointContainer::FindConnectionPoint, using the GUID that represents the desired interface. If the object implements that outgoing interface, the object hands back a pointer to that connection point. At that point, the client uses that IConnectionPoint interface pointer and calls

 IConnectionPoint::Advise(
[in] IUnknown *pUnk, [out] DWORD *pdwCookie) 
to hand over its implementation of the callback interface so that the object can call back to the client. To make it clear once more, the pointer to IUnknown passed to the advise method is the pointer of an interface that's defined and implemented in the client EXE.

Okay, now let's illustrate the whole thing by a practical example.

  1. Create a new ATL-COM AppWizard Project and name it ConnectionCOM.
  2. Right-click on the class view and create a new ATL object.

    Image 2

    Image 3

    Name it Add (interface IAdd).

    Image 4

    Before you click the OK button, be sure to check the Support Connection point checkbox.

    Image 5

    Click OK.

Note the classes generated in the class view. You will find one IAdd and _IAddEvents. The latter is just a proxy class; it is to be implemented on the client side. It came because we ticked the Connection_Points check box.

Add a method 'Add(int a,int b) ' to IAdd interface and a method 'ExecutionOver(int Result)' to the _IAddEventsInterface. The class view will be as shown below.

Image 6

But because we have selected a dual interface and we do not need all that hassle, let's take out the support for IDispatch by editing the IDL file. Below is the original file.

//===========================================================
// ConnectionCOM.idl : IDL source for ConnectionCOM.dll
//
  :
  :

library CONNECTIONCOMLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");

[
  uuid(AFE854B0-246F-4B66-B26F-A1060225C71C),
  helpstring("_IAddEvents Interface")
]
// Old block - take this out
// dispinterface _IAddEvents
// {
// properties:
// methods:
// [id(1), helpstring("method ExecutionOver")]
// HRESULT ExecutionOver(intResult);
// };
//To this one -put this in
interface _IAddEvents : IUnknown
  {
  [id(1), helpstring("method ExecutionOver")] HRESULT
          ExecutionOver(intResult);
  };
  [
    uuid(630B3CD3-DDB1-43CE-AD2F-4F57DC54D5D0),
    helpstring("Add Class")
  ]
  coclass Add
  {
  [default] interface IAdd;
  //[default, source] dispinterface _IAddEvents; take this line
  //out and put the line below in
  [default, source] interface _IAddEvents ;
  };
};

//================================================================

Whew! The client side is almost finished now. Now, do a build because we need the type library to do a neat thing with ATL. Now, right-click on the CoClass and click Implement Connection Point.

Image 7

Check _IAddEvents in the ensuing dialog box.

Image 8

A CProxy_IAddEvets class is generated with the Fire_ExecutionOver(int result) method. This will take care of how the COM object will call the client interface (and takes care of multiple clients calling the same COM DLL and other such issues). Now, let's implement our old IAdd Interface Add method.

//=====================================================

STDMETHODIMP CAdd::Add(int a, int b)
{
// TODO: Add your implementation code here

Sleep(2000);   // to simulate a long process

//OK, process over now; let's notify the client

Fire_ExecutionOver(a+b);

return S_OK;
}
//======================================================

Do a build and the COM is ready. Make sure that the COM is registered.

Now the Client Side

Create a new MFC AppWIzard(exe) Dialog based project - ConnectionClient. It looks like this:

Image 9

Now comes the main part.

We create a CSink class that derives form _IAddEvents. You can use the class wizard for it. You have to supply the header where the _IAddEvents interface is defined. For that, copy the ConnectionCOM.h and ConnectionCOM.tlb files to your client EXE's project folder and add these lines to Sink.h file.

#include "ConnectionCOM.h"
#import "ConnectionCOM.tlb" named_guids raw_interfaces_only

Now we have the additional task of implementing each method defined in the _IAddEvents interface. (Never forget that a COM interface is just a pure abstract base class and that the derived class has to implement all of its methods.)

So, let's implement the first ExecutionOver:

STDMETHODIMP ExecutionOver(int Result)
  {
  CString strTemp;
  strTemp.Format("The result is %d", Result);
  AfxMessageBox(strTemp);
  return S_OK;;

  };

Now comes QueryInterface, AddRef, and Release.

HRESULT STDMETHODCALLTYPE QueryInterface(REFIID iid, void
                                         **ppvObject)
  {
    if (iid == IID__IAddEvents)
    {
      m_dwRefCount++;
      *ppvObject = (void *)this;
      return S_OK;
    }
    if (iid == IID_IUnknown)
    {
      m_dwRefCount++;
      *ppvObject = (void *)this;
      return S_OK;
    }
    return E_NOINTERFACE;
  }

ULONG STDMETHODCALLTYPE AddRef()
  {
    m_dwRefCount++;
    return m_dwRefCount;
  }

ULONG STDMETHODCALLTYPE Release()
  {
    ULONG l;
    l  = m_dwRefCount--;
    if ( 0 == m_dwRefCount)
       delete this;

    return l;
  }

We are now almost there.

Now, on the dialog class on the SendToServer Button Click event, we shall do the last bit of coding.

#include "Sink.h"          // for our CSink class
#include <atlbase.h>       // for ATL smart pointers

void CConnectionClientDlg::OnSendToServer()
     //SendToServer button click event
{
UpdateData(1);
HRESULT hr;

//call CoInitialize for COM initialisation

hr =CoInitialize(NULL);
if(hr != S_OK)
  return -1;

// create an instance of the COM object

CComPtr<IAdd> pAdd;
hr =pAdd.CoCreateInstance(CLSID_Add);
if(hr != S_OK)
  return -1;

IConnectionPointContainer  * pCPC;
  //IConnectionPoint       * pCP;
  //these are declared as a dialog's member
  //DWORD                  dwAdvise;
  //variables,shown here for completeness

  //check if this interface supports connectable objects

  hr = pAdd->QueryInterface(IID_IConnectionPointContainer,
                           (void **)&pCPC);

  if ( !SUCCEEDED(hr) )
  {
    return hr;
  }

  //
  //OK, it does; now get the correct connection point interface
  //in our case IID_IAddEvents

  hr = pCPC->FindConnectionPoint(IID__IAddEvents,&pCP);

if ( !SUCCEEDED(hr) )
  {
    return hr;
  }

//we are done with the connection point container interface

pCPC->Release();

IUnknown *pSinkUnk;

// create a notification object from our CSink class
//

CSink *pSink;
  pSink = new CSink;

  if ( NULL == pSink )
  {
    return E_FAIL;
  }

  //Get the pointer to CSink's IUnknown pointer (note we have
  //implemented all this QueryInterface stuff earlier in our
  //CSinkclass

hr = pSink->QueryInterface (IID_IUnknown,(void **)&pSinkUnk);

//Pass it to the COM through the COM's _IAddEvents
//interface (pCP) Advise method; Note that (pCP) was retrieved
//through the earlier FindConnectoinPoint call
//This is how the com gets our interface, so that it just needs
//to call the interface method when it has to notify us

hr = pCP->Advise(pSinkUnk,&dwAdvise);

//dwAdvise is the number returned, through which
//IConnectionPoint:UnAdvise is called to break the connection

//now call the COM's add method, passing in 2 numbers
  pAdd->Add(m_number1 ,m_number2);
//do whatever u want here; once addition is here a message box
//will pop up showing the result

//pCP->Unadvise(dwAdvise); call this when you need to
//disconnect from server
pCP->Release();

  return hr;
}

Now, do a build of the dialog EXE. Now fire away. That's it for connection points.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


Written By
Architect
India India
Hi everyone!! Sometimes I get real stumped with some concepts and that gets me excited.So I say - hey let me explore - and there I go!! .Currently I am working as software engineer for Nokia Siemens Networks, Bangalore -India.My dream subject - Physics!!

Comments and Discussions

 
QuestionPointer in the event? Pin
Banjo6-Feb-03 4:30
Banjo6-Feb-03 4:30 
GeneralSinking events Pin
Chopper22-Jan-03 23:12
Chopper22-Jan-03 23:12 
GeneralRe: Sinking events Pin
earlster2-Dec-04 15:53
earlster2-Dec-04 15:53 
GeneralGreat article! Pin
Marc Clifton22-Jan-03 14:03
mvaMarc Clifton22-Jan-03 14:03 
GeneralRe: Great article! Pin
Stephane Rodriguez.22-Jan-03 21:10
Stephane Rodriguez.22-Jan-03 21:10 
GeneralRe: Great article! Pin
Marc Clifton23-Jan-03 0:19
mvaMarc Clifton23-Jan-03 0:19 
GeneralRe: Great article! Pin
Aldamo23-Jan-03 19:16
Aldamo23-Jan-03 19:16 
GeneralRe: Great article! Pin
Marc Clifton24-Jan-03 0:31
mvaMarc Clifton24-Jan-03 0:31 
In my opinion, VB gives one the illusion of a professional product, while underneath is a slow and buggy engine. I've worked on several contracts that required VB and I found working with it to be frustrating. It wasn't necessarily VB, but the whole environment and style to which Microsoft requires you to conform. I also found that the other programmers on the team were pretty much ignorant of good programming practices--but that's because you have to go out of your way to use them with VB, even more so than with all the wizards that Visual C++ provides. Management often requires VB because they have the illusion that it's easier to use, and therefore programmers are cheaper. In the long run, it's costs more.

However, you are correct--I shouldn't have criticized VB programmers.

Marc

Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.