Microsoft KB Archive/206998

= PRB: Problems Printing ActiveX Control on HTML Page =

Article ID: 206998

Article Last Modified on 5/11/2006

-

APPLIES TO


 * Microsoft Internet Explorer 4.0 128-Bit Edition
 * Microsoft Internet Explorer 4.01 Service Pack 2
 * Microsoft Internet Explorer 4.01 Service Pack 1
 * Microsoft Internet Explorer 4.01 Service Pack 2
 * Microsoft Internet Explorer 5.0
 * Microsoft Internet Explorer 5.01
 * Microsoft Internet Explorer (Programming) 5.01 SP1
 * Microsoft Internet Explorer 5.5

-



This article was previously published under Q206998



SYMPTOMS
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.



CAUSE
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.



RESOLUTION
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



STATUS
This behavior is by design.



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.

