Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

PRB: Problems Printing ActiveX Control on HTML Page

View products that this article applies to.


ActiveX controls on HTML pages may fail to print properly in Internet Explorer 4.0 or later. The control either prints using default values, loses data entered into the control before printing, or loses values for some control properties.

↑ Back to the top


As of version 4.0, Internet Explorer uses background printing for HTML pages. This allows the user to continue using the browser while the page is printing in the background. To implement this functionality, Internet Explorer instantiates a second copy of the page by saving the current state of the HTML page to a temporary file and then reloading this file in a new instance of the HTML parser.

For pages that contain ActiveX controls, the ActiveX control data must also be persisted. It is saved, usually into a property bag, and then reloaded in a new instance of the control. If a control fails to persist itself correctly, the printing instance of the control will not get the data of the visible control and will print incorrectly.

↑ Back to the top


To solve this problem, ensure that all ActiveX controls used on HTML pages properly support property and data persistence.

MFC controls should include PX_ tags for all essential properties inside the COleControl::DoPropExchange override. These persisted properties need to expose data such that when the control is reloaded in the secondary HTML page, it can restore the state of the control. This includes any data that was dynamically added to the control by the user or script.

Also, controls should make no assumptions about the kind of device context (DC) they will be given when they are asked to draw, as they will be asked to draw for the printer in the same manner they are asked to draw for the screen.

Last, ActiveX controls will not be UI Activated during the printing, and any display code in the control that relies on Windows will likely fail and draw incorrectly. When necessary, the workaround described in the following article in the Microsoft Knowledge Base can be used to force window creation without relying on UI activation:
195188 PRB: ActiveX Control Window Is Not Created Until Visible in Internet Explorer

↑ Back to the top


This behavior is by design.

↑ Back to the top

More information

Some controls persist only design-time properties that affect the display of the control. These controls need to be updated to print correctly in Internet Explorer.

↑ Back to the top


For more information about developing Web-based solutions for Microsoft Internet Explorer, visit the following Microsoft Web sites:

↑ Back to the top


Retired KB Content Disclaimer
This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.

↑ Back to the top

Keywords: kbctrl, kbctrlcreate, kbdhtml, kbfaq, kbprb, KB206998

↑ Back to the top

Article Info
Article ID : 206998
Revision : 3
Created on : 5/11/2006
Published on : 5/11/2006
Exists online : False
Views : 393