BUG: ATL Control in Office Document Prevents Another Control's Events from Working
ID: Q241861
|
The information in this article applies to:
-
Microsoft Excel 2000
-
Microsoft Excel 97 for Windows
-
Microsoft Word 2000
-
Microsoft Word 97 for Windows
-
Microsoft PowerPoint versions 2000, 97 For Windows
-
The Microsoft Active Template Library (ATL), versions 2.0, 3.0
-
Microsoft Visual Basic for Applications (VBA) 5.0 Software Development Kit (SDK), version 1.0
SYMPTOMS
An ATL Control inserted into an Office 97 or Office 2000 document (that is, an Excel spreadsheet, PowerPoint presentation, or Word document) causes VBA to not receive events for other controls in the same document. The other controls may fire events, but the VBA code in the event handlers will not run. If the ATL control is removed, events for the other controls work as expected.
CAUSE
When a control is inserted into a document, VBA checks for an outgoing event interface in the type library for the control. If an outgoing event interface is not supplied, it effects the behavior of event handling for the rest of the controls in the document.
RESOLUTION
For Visual Basic applications to function properly, an outgoing event interface must appear in the control's coclass definition. The event interface does not have to be used or implemented, but the even interface must be in the type library.
By default, when you create a new ATL control, Full or Composite, an event interface is not generated if the "Support Connection Points" checkbox is not selected under the Attributes tab from the ATL Object Wizard.
If an event interface was not added with the help of the ATL Object Wizard, you will need to add the event interface to the control manually. You can do this by manually editing the wizard generated IDL code for the ATL control.
The following two code snippets need to be added to the IDL code:
//Add this before the library block in your IDL code
//Begin new code
[
uuid(DC2EF6F1-136F-11d3-8C6C-00C04F542A77),
helpstring("IUseATLInExcelEvents Interface"),
]
dispinterface IUseATLInExcelEvents
{
};
//End new code
//You need to update the coclass to show an event interface
//Just add the code below marked with //Begin new code and //End new code.
//The rest of the code was just provided as a reference point on where
//to add the new code.
[
uuid(6734BB80-136B-11D3-8C6C-00C04F542A77),
version(1.0),
helpstring("ATLVBATest 1.0 Type Library")
]
library ATLVBATESTLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");
[
uuid(6734BB8D-136B-11D3-8C6C-00C04F542A77),
helpstring("ATLVBA2 Class")
]
coclass ATLVBA2
{
[default] interface IUseATLInExcel;
//Add the following line to any coclasses in the IDL file that are controls
//and do not have a default, source interface.
//Begin new code
[default, source] dispinterface IUseATLInExcelEvents;
//End new code
};
};
Once the control is rebuilt and re-registered, it should behave correctly when inserted into Excel. If it still does not behave correctly, you may want to look at the the following KB article:
Q185473 Changes to Custom ActiveX Controls Are Not Used
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed
at the beginning of this article.
REFERENCES
Step 5 of the ATL Tutorial in MSDN. It is located in the index under: ATL Tutorial.
Additional query words:
events hang nonresponsive source default required IConnectionPoint IConnectionPointContainer
Keywords : kbActiveX kbATL kbCtrlCreate kbExcel KbVBA kbPowerPt kbWord kbGrpDSO kbExcel97 kbDSupport kbWord97 kbGrpMFCATL kbexcel2000 kbpowerpt2000 kbword2000
Version : WINDOWS:2.0,2000,3.0,97; winnt:1.0
Platform : WINDOWS winnt
Issue type : kbbug