PRB: ATL Control Appears Incorrect in Access Report (242002)
The information in this article applies to:
- The Microsoft Active Template Library (ATL) 3.0
- Microsoft Access 2002
- Microsoft Access 2000
- Microsoft Access 97
This article was previously published under Q242002 SYMPTOMS
An ATL ActiveX Control does not appear or appears incorrectly when added to a Microsoft Access Report. The same control displays correctly when the Report is in design mode or if the control is added to an Access Form.
CAUSE
Microsoft Access uses different drawing methods for rendering a control on a Report and rendering it on a Form. When placed on a Report, the control is asked for a metafile presentation that Access uses to render the control when previewing or printing the report. The control itself (that is, the control window) is only displayed when in design mode. The problem is that the metafile being rendered by the ATL control is incorrect.
When Access requests that the control draw itself (through IViewObject::Draw), ATL uses the GetDeviceCaps API and the TECHNOLOGY index to determine whether the HDC passed as a parameter to the function is a metafile device context. Under certain circumstances, this call does not succeed in detecting that a metafile is indeed being used, so ATL treats the bounding RECT coordinates as screen coordinates instead of HIMETRIC units.
RESOLUTION
To resolve the problem, change the code that checks the device context so that it also checks if the bounding window RECT passed in from IViewObject::Draw is NULL. If the parameter is NULL, a metafile is not being drawn. See the sample below to demonstrate the workaround.
REFERENCESFor additional information regarding ATL controls in Access, click the article number below
to view the article in the Microsoft Knowledge Base:
197490 PRB: ATL Full Control Needs Enabled Stock Property for Access 97
Modification Type: | Major | Last Reviewed: | 6/24/2004 |
---|
Keywords: | kbCtrlCreate kbprb KB242002 |
---|
|