December 1999

Code for this article: Dec99VP.exe (295KB)

George Shepherd is an instructor with DevelopMentor and a Software Engineer at RogueWave Software. George is coauthor of MFC Internals (Addison-Wesley, 1996) and Programming Visual C++ (Microsoft Press, 1998).

Q I am developing an ActiveX® control using MFC. The control lives in a DLL. Once the control is invoked from Visual Basic®, I want to be able to step into the control's source code to debug. Is this possible? How do I do it? Harry Feng via the Internet A Debugging ActiveX controls residing in a DLL involves a little trick surprisingly few folks know. To debug any COM object residing in a DLL, simply load the DLL into Visual Studio®, select Settings from the Project menu, then point the "Executable for debug session" field in the Debug tab to the Visual Basic executable, as shown in Figure 1.

Figure 1 Debugging an ActiveX Control from within Visual Basic

Set your breakpoints in the object's source code, press F5 to start the debugger, and sit back to watch the fireworks. Q I am trying to use a C++ ActiveX-based DLL that contains two source interfaces. I can get the default interface without any problem. Is there any way of getting the events from the nondefault source interface? Pieter Oosthuizen via the Internet A There are a few answers, depending upon the client environment, so I'll cover what it takes to connect to an object using nondefault source interfaces from ATL and MFC-based clients.       The sample is an ActiveX control created using ATL and living in a DLL named AnATLDLLSvr. There's nothing really special about this control except that it describes two outgoing interfaces: _IControlWithMultipleEventsEvents and _IControlWithMultipleEventsMoreEvents. Figure 2 shows the control's IDL code and how the control exposes the two outgoing interfaces.       Notice how the interfaces are described as plain old IDispatch interfaces (via the dispinterface keyword) and that they're labeled as source interfaces. The source keyword tells the world that they are outgoing interfaces—that is, they are interfaces to be implemented by the client. The default keyword tells interested clients that _IControlWithMultipleEventsEvents is the default source interface. For example, this is the interface Visual Basic uses to connect via the WithEvents keyword and that Visual Studio uses when manufacturing event handlers for your MFC-based client app. Let's start with setting up multiple event sinks with ATL. The ATL Answer       In some ways, it's easier to set up multiple event sinks with ATL because ATL is so close to COM; it's really no problem managing the interfaces involved in setting up multiple event sinks. In fact, ATL has a very useful wrapper class for managing IDispatch-based event sinks, IDispEventImpl, which is defined as:

 template <UINT nID, class T, 
     const IID* pdiid = &IID_NULL, 
     const GUID* plibid = &GUID_NULL, 
     WORD wMajor = 0, WORD wMinor = 0, 
     class tihclass = CComTypeInfoHolder>
     class ATL_NO_VTABLE IDispEventImpl : 
     public IDispEventSimpleImpl<nID, T, pdiid>
 {
     // Yadda, yadda, yadda...
 }

 // The Event Sink's .CPP file...
 // from the files generated by Class Wizard
 BEGIN_INTERFACE_MAP(EventSinkImpl, CCmdTarget)
     INTERFACE_PART(EventSinkImpl,
         DIID__IControlWithMultipleEventsMoreEvents, 
         Dispatch)
 END_INTERFACE_MAP()

 class CMFCUsemultipleeventsetsDlg : public CDialog
 {
 // Regular MFC stuff...
     DWORD m_dwCookie;
     IUnknown* m_pUnkEventSink;
 
     EventSinkImpl m_eventSinkImpl;
 };

 CMFCUsemultipleeventsetsDlg::CMFCUsemultipleeventsetsDlg(
     CWnd* pParent)
     : CDialog(CMFCUsemultipleeventsetsDlg::IDD, 
               pParent)
 {
     // Regular MFC initialization...
     m_dwCookie = 0;
     m_pUnkEventSink = 
         m_eventSinkImpl.GetIDispatch(FALSE);
 }

 BOOL CMFCUsemultipleeventsetsDlg::OnInitDialog()
 {
     // Normal init goes above here...
 
     IUnknown* pUnk = NULL;
 
     pUnk = m_ctl.GetControlUnknown();    
     if(pUnk)
     {
         AfxConnectionAdvise(pUnk, 
             DIID__IControlWithMultipleEventsMoreEvents,
             m_pUnkEventSink, 
             TRUE, &m_dwCookie);
     }
 
     return TRUE;  
 }